CODEWITHSUNDEEP
composer-php
Tim Morton
Tim Morton

Reputation: 2644

Composer and local dependencies

I am wanting to use Composer to manage my own private libraries used at work, and use them on intranet projects at work.

Publishing code to packagist or github is NOT an option per company rules; all code is to remain within our own walls so to speak.

I have figured out how to include libraries into my intranet web app on an individual basis:

composer.json for web app

{
    "name": "myapp/appname",
    "description": "app that uses some of my libraries",
    "require": {
      "tmorton/dataaccessobjects": "^1.0.0"
    },
    "repositories": [
      {
        "type":"vcs",
        "url":"//path/to/library"
      }

    ]
}

My problem is that this collection of data access objects has a dependency on my crud library.

So it seems that I should be able to require the crud library in the composer.json in the dataaccessobjects library:

composer.json for data access objects

{
    "name": "tmorton/dataaccessobjects",
    "description": "Data Access Objects for a set of specific tables",
    "type": "library",
    "license": "proprietary",
    "repositories": [
      {
        "type": "path",
        "url":"//path/to/crud/library"
      }
    ],
    "minimum-stability": "dev",
    "require": {
      "tmorton/crud": "^2.0.0"
    }
}

My DAO objects are cloned into app/vendor, but Crud is not brought in.

All the documentation I've seen talks about publishing to third party locations, but nothing about from local sources.

I can, of course do this; but it defeats the whole idea of managing dependencies (I shouldn't have to know which version of crud is required at this point)

composer.json for web app

{
    "name": "myapp/appname",
    "description": "app that uses some of my libraries",
    "require": {
      "tmorton/dataaccessobjects": "^1.0.0",
      "tmorton/crud": "^2.0.0"
    },
    "repositories": [
      {
        "type":"vcs",
        "url":"//path/to/dao/library"
      },
      {
        "type": "path",
        "url":"//path/to/crud/library"
      }

    ]
}

I'm hoping somebody can fill in some concepts that I appear to be missing.

The answer to a suggested question seems to indicate that type: "package" won't work. I'm not using type: "package".

package type is for non-composer dependencies. If you use this type, Composer will not even look for composer.json file inside of defined package source, you need to include all required information about package inside of the package declaration in your project composer.json

What I'm gathering is that no matter what you do, composer-- by itself-- isn't going to bother looking up dependencies of included items. Somehow it works when grabbing 3rd party stuff, but there's obviously something else doing the work. My guess is it's the hosting itself?

Upvotes: 0

Views: 1075

Answers (1)

ivoba
ivoba

Reputation: 6026

I see that running a intranet satis comes with some overhead of administrating which is why i also stopped using it.

Here is what i would recommend in your situation:

  1. Use git for internal packages:
    You have a private git repo somewhere and require this with the repository directive of composer

    "require": {
    "my/package": "dev-main"
    ...
    },
    "repositories": [
    {
    "type": "git",
    "url": "[email protected]:my/package.git"
    }
    ]

Of course don't commit the vendor dir but do commit composer.lock.

Update:
Note that you will need to add repositories of private subpackages also in the repositories block of the project's composer.json. So when my/package requires another private package my/package2, add thismy/package2 as well to repositories block of your projects composer.json.

  1. Use builds for deployment
    With tools like deployer you can easily run composer on production and symlink to the succesfull build/release after all is run.
    Here you also have a dependency on composer on your production machine, but deployer usually installs the phar itself, outside the web root.
    If this is not suitable you can also do a local build with deployer and sync to your production system via rsync: https://deployer.org/docs/advanced/deploy-strategies.html#build-server
    Here you locally checkout from git in a build dir, run there composer locally and push to production via rsync.

Upvotes: 1

Related Questions