Namespacing Composer extra configs

[apiuser]

Feature request from nevvermind, posted on GitHub Jun 18, 2015

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.

[apiuser]

Comment from buskamuza, posted on GitHub Jun 19, 2015

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.

[apiuser]

Comment from nevvermind, posted on GitHub Jun 19, 2015

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.

[apiuser]

Comment from Vinai, posted on GitHub Jun 22, 2015

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

[apiuser]

Comment from joshdifabio, posted on GitHub Jun 22, 2015

:+1: 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.

[apiuser]

Comment from nevvermind, posted on GitHub Jun 22, 2015

@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?

[apiuser]

Comment from Vinai, posted on GitHub Jun 22, 2015

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.

[apiuser]

Comment from nevvermind, posted on GitHub Jun 22, 2015

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.

[apiuser]

Comment from buskamuza, posted on GitHub Jun 25, 2015

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

[apiuser]

Comment from piotrekkaminski, posted on GitHub Aug 03, 2016

@buskamuza was it ever done?