Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cannot override vendor's composer.json autoload in project's composer.json #1100

Closed
jonathaningram opened this issue Sep 12, 2012 · 3 comments
Labels
Milestone

Comments

@jonathaningram
Copy link
Contributor

I was using the autoload section of composer.json to allow a dev copy of my acme/library repository to be loaded before the copy in the vendor folder. This means that in development I can edit the library files locally and they will be loaded before the version installed in vendor. In production, it doesn't matter because only the vendor/acme/library version exists.

The composer.json section is like this:

{
    "autoload": {
        "psr-0": {
            "": "src/",
            "Acme": "acme-library/src/"
        },
    }
}

In that file, acme-library is a symlink that exists at the root of the project.

Prior to the fix in #1051, my generated autoload file would look like this:

<?php

return array(
    'Acme' => array($baseDir . '/acme-library/src/', $vendorDir . '/acme/library/src/'),
);

Now, the values in that array are reversed which means that $vendorDir . '/acme/library/src/' is loaded first and thus my locally changed library files do not get included.

Refs #1051, refs #1017

@simensen
Copy link
Contributor

This was addressed at least once awhile back in #204. It had a test and a fixture that have since been removed. I have no idea what happened in #1051 that broke this but I depend on the original behavior of root package PSR-0 autoload taking precedence over dependencies PSR-0 autoload as well.

@jonathaningram
Copy link
Contributor Author

@Seldaek is appears this was fixed since a week or two. Was this on purpose or a by-product of something else? Either way, it may need a test case to prove.

@Seldaek
Copy link
Member

Seldaek commented Oct 23, 2012

Oh right yes it was fixed by @hason's PR linked above, and it included new tests which I think cover this case.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants