Proposal: Introduce a separate repositories-dev section in composer.json
#12693
Replies: 1 comment 3 replies
-
|
This has a huge risk that your composer.lock file is unusable for production installs. A |
Beta Was this translation helpful? Give feedback.
-
|
Thank you for pointing out the fundamental difference between I understand that Our primary goal, therefore, is to control the repository sources during Reframed Proposal:The functionality of This injection would ensure that:
Given this context—that the control is needed during the update/resolve phase—are there any recommended configuration environment variables or plugin hooks that can be used today to conditionally inject a repository definition into the resolver before it starts processing, specifically based on the presence of the We appreciate the insight and are looking for the best way to achieve this clean separation within the current Composer architecture. |
Beta Was this translation helpful? Give feedback.
-
|
the |
Beta Was this translation helpful? Give feedback.
-
|
Because dev requirements and their own requirements can influence what non-dev requirements end up being chosen, we cannot resolve dependencies in isolation. Dependencies are always all resolved together and then the --no-dev just changes what gets installed. So I don't think this is doable at all. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Category
Ideas
Content:
Hello Composer community and maintainers,
I'd like to propose a discussion about potentially introducing a separate section for development-only package repositories, such as
repositories-dev, alongside the existingrepositoriessection incomposer.json.Currently, the
repositoriessection is global, meaning all listed sources are consulted for both production (require) and development (require-dev) dependencies.Problem/Context:
While the current behavior is generally acceptable, it presents challenges, particularly in large projects or monorepos where we often use
type: "path"repositories for local package development.repositoriessection can lead to unnecessary metadata or potential confusion about source availability in production/CI environments, even if the dependencies are correctly managed underrequire-dev.repositories-devsection would clearly communicate that certain repositories (especially local ones liketype: "path") are only relevant during development cycles and should be ignored entirely when runningcomposer install --no-dev.Proposed Solution:
Introduce a new, optional section,
repositories-dev, that would function identically torepositories, but only be active when development dependencies are installed (i.e., when--no-devis not used).{ "repositories": [ { "type": "vcs", "url": "[email protected]:owner/repository.git" }, ], "repositories-dev": [ { "type": "path", "url": "../packages/...", "options": { "symlink": true } } ] }This change would benefit the community by:
Improving Clarity: Making the intent of local development setups more explicit.
Encouraging Best Practices: Simplifying the separation of concerns between production and development package sources.
What are the community's thoughts on this proposal, potential implementation challenges, or known reasons why this structure has been avoided so far?
Thank you for your time.
Beta Was this translation helpful? Give feedback.
All reactions