-
-
Notifications
You must be signed in to change notification settings - Fork 134
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
[RFC] Provide unpolyfill meta-package #225
Comments
@jderusse even if your proposal would be useful, I think this is something that should be solved on Composer side. We need an option to tell Composer: "ignore this package completely if ...." and the conditions are: PHP version and/or PHP constraints. E.g.: {
"name": "symfony/polyfill-intl-icu",
"ignore-if": {
"ext-intl": "*"
},
"...": "..."
} {
"name": "symfony/polyfill-php72",
"ignore-if": {
"php": "^7.2.0"
},
"...": "..."
} |
There is a feature request: composer/composer#7557 that would solve this issue. So far nobody provided a PR for this. |
@javiereguiluz the issue with that on the composer side is that the lock file would then depend on this |
To handle extension polyfills properly (php version polyfills would not be solved by that idea), the cleaner solution would actually be to solve the issue with packages providing extensions (see composer/composer#5030, which might be solved in Composer 2 due to the refactoring of the solver btw, but I haven't verified it). |
We could have flex handle this for us: when the extension is here, it would add it to the composer.lock file and it would remove the corresponding polyfills. PR welcome on flex :) |
hmm.. it requires using flex, moreover how flex knows that a polyfill can be removed? Because an ext appear in the "suggest"? Or because it match "/polyfill-" or "/compat-".?// |
Altering the lock file is very risky, as |
It requires using flex, yes, no issues here, that's what plugins are for, enhancing composer.
Because we know the rules and we can code them into it. It's not like new polyfills popup everyday. That's a very finite domain.
I meant before running the solver, in a way that would make composer scream if you "composer install" without the extension while flex made composer take it into account. I think we have the same constraints in mind :) |
IMO in Composer 2.0 it would be possible to do something like @javiereguiluz suggested, a new field on packages like I can't guarantee 100% that this works but I believe it's much more doable now as the lock file construction/composer update is not looking at the installed.json anymore. The benefit is that it is in the lock file, so depending on the real PHP version you execute with it would be installed or not (I think platform config should be ignored for this). Now obviously the problem is that as we saw with the php version being different at runtime than at composer install time, people do crazy things sometimes. So this probably would end up breaking in some places where people would run install with a newer php than they have in prod and then the polyfill would be missing. Not sure if it's worth all this trouble and potential issues just to save a few |
For what its worth, an idea proposed in #138 was to have a version So users could require |
that won't work if you require a library that requires |
True, its also a chance to open a PR to that package to change that. Its not the perfect solution, and that is one of the reasons the PR wasn't merged. But it is one of the few options we have with current tooling. |
I'm closing here as this repo won't provide the solution. |
When extension is installed, the related polyfill is not need, but is still downloaded + bootstraped.
The idea is to provide composer meta-package (without code) to avoid that
users can just
composer req symfony/not-polyfill-php73
to remove those un-needed packages.WDYT?
The text was updated successfully, but these errors were encountered: