Feature proposal: Ability to create more specific groups inside of require-dev and `dev
#9923
jacobbednarz
started this conversation in
General
Replies: 1 comment 1 reply
-
|
Linking #9636 as it looks to be a similar-ish issue that would also benefit from this improvement however in a more general fashion. I think defining the schema based on the proposed fields is eventually going to run into the same issues once a new category of groups is generated. |
Beta Was this translation helpful? Give feedback.
1 reply
-
|
This has been discussed in the past and IMO there is close to zero chance we will add more of |
Beta Was this translation helpful? Give feedback.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
Coming from a package manager like Ruby's bundler, one of the features I'm often missing is the ability to be more specific about my
requires andrequire-devs instead of the current all or nothing approach. I think it would be benefitical to introduce a similar concept to include or exclude "groups" of dependencies via CLIinstallflags.Let's consider an example scenario where you have dev, test, stage and production. In all environments you have pretty well the same amount of runtime dependencies being loaded in
requirehowever in dev and stage, you now also need some internal tooling to help diagnose some issues. This functionality is potentially dangerous to run in production so you don't want to include it all by default. Similarly, in the test environment, you have runtime dependencies but you don't need or want to include them in all environments as they are solely for running tests. In the current landscape,require-devis often (ab)used to handle the last scenario and while it works, it doens't lend itself to much flexibility.Right now, it's pretty messy to handle this and the current Composer file design doesn't really facilitate it (which is expected as it hasn't been a need) but in the future, I think we could improve these types of scenarios by including an option such as
--withor--withoutfor the install commands that would faciliate being more flexible about what to install.I haven't though too much about the design of the
composer.jsonfile however to make it backwards compatible, the object keys could remain prefixed withrequire_and the--with/--withoutcould use them. (Eventually thought we'd rip off the bandaid and rename the keys to be more informative with therequireprefix and potentially nested)For example:
{ "require": { "example/example-dep-for-all": "*" }, "require-dev": { "example/dev-1": "*", "example/dev-2": "*", "example/dev-3": "*" }, "require-stage": { "example/stage-1": "*", "example/stage-2": "*", "example/stage-3": "*" }, }And an invocation for only the staging setup.
Alternatively, we could also continue the path of the current set of flags with the
--noprefix (such as `--no-dev).Thoughts?
Beta Was this translation helpful? Give feedback.
All reactions