Namespacing Composer extra configs

[nevvermind]

As Composer packages get used more and more, if not careful, some of their extra configuration may clash at some point in the future.

Not only that, but having an en-gross extra object, it won't be easy to figure out which config belongs to what package.

It would be great if Magento 2 would spearhead good practice (in my opinion at least) and use namespaced configs. We already have the best candidate for this: the package vendor + name combo - magento/magento2ce:

"extra": {
    "magento": {
        "magento2ce": {
            "component_paths": {
                "package-specific": "stuff"
            }    
        }
    }
}

If not good practice, at least M2 will shield itself from possible conflicts with other package configs.

This seems like a small change anyway. But with lots of benefits from where I'm standing.

[buskamuza]

Hi @nevvermind , good idea. I'd use "magento/magento2", not "magento2ce" because CE is just a combination of Magento 2 components, but the logic is applicable for any M2 component (even, if it's not in CE).

Another concern here is that this component_paths is introduced by the original Hackathon Composer Installer for M1 and we based M2 installer on it. Changing the path now may confuse the ones, who already used the Hackathon installer. Also, for anybody who already implemented extensions for M2, this part must be changed to be compatible with the installer. Which sounds risky change. Still not so risky now, as after stable release.

Also, in general we try to eliminate usage of such installer at all and make components work from vendor folder directly (see #1013, #1206).

To conclude: it's a good idea for the base implementation of the installer, but I'm not sure that it will give much benefit now, when it's already in use. But thanks for the proposal, maybe we'll hear other thoughts about this here.

[nevvermind]

I'd use "magento/magento2", not "magento2ce" because CE is just a combination of Magento 2 components, but the logic is applicable for any M2 component (even, if it's not in CE).

Yeah, I used "magento2ce" just to emphasize the <vendor>/<package> duo. But I still think it's better to use the package name exactly, just to stick to a standard, othewise it's back to people using whatever they want.

Another concern here is that this component_paths is introduced by the original Hackathon Composer

I didn't know. I assumed it was yours. In this case, yeah, you shouldn't change that. You should change only what's Magento's.

[Vinai]

👍 for breaking bc now during the beta. 👍👍👍 if breaking bc helps adoption of placing modules directly into vendor.

[joshdifabio]

👍 for breaking bc now during the beta.

I agree. I believe that any third parties developing for Magento 2 at this relatively early stage will be expecting BC breaks.

[nevvermind]

@Vinai @joshdifabio - not sure exactly what you mean by "BC break" here. You mean to change the installer's extra config to a namespaced one?

[Vinai]

Yes, I think we are on the same page. In this case breaking BC means changing the composer.json extra configuration structure in a way that requires existing modules to be updated in order for them to continue to work.

[nevvermind]

This doesn't require other modules to change. Does it? It's only Magento2's code that needs a slight adjument - https://github.com/magento/magento2/search?utf8=%E2%9C%93&q=component_paths. Where's the BC break?

Another concern here is that this component_paths is introduced by the original Hackathon Composer

I didn't know. I assumed it was yours. In this case, yeah, you shouldn't change that. You should change only what's Magento's.

I got a little confused, because the hackathon installer is a fork, so M2 can change it. And I think they should.

[buskamuza]

@nevvermind , existing extensions will have to change "extra" section you described in the original post in their composer.json files.

[piotrekkaminski]

@buskamuza was it ever done?

[piotrekkaminski]

Thank you for your submission.

We recently made some changes to the way we process GitHub submissions to more quickly identify and respond to core code issues.

Feature Requests and Improvements should now be submitted to the new Magento 2 Feature Requests and Improvements forum (see details here).

We are closing this GitHub ticket and have moved your request to the new forum.