You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently you have to list all external dependencies together in the shared composer.json, however this does not make it clear what the needs are for any individual module (subfolder), and may cause the inclusion of unnecessary dependencies when only certain modules are desired.
Phase 1: Configuration
All composer-dependencies (and their versions) will continue to be listed in composer.json.
Each module's fiddler.json file shall support two new sections, require and require-dev. These sections contain an array of strings, where each string is the name of a composer-dependency that it relies upon.
Every require dependency in a fiddler.json must have a direct corresponding entry in the require section of composer.json.
Every require-dev dependency in a fiddler.json must have a corresponding entry in the require-devorrequire sections of composer.json.
Every require or require-dev entry in composer.json that does not have any corresponding entry somewhere in at least one fiddler.json file should cause a warning message, since it may indicate an unnecessary or unclear dependency.
The benefit of this feature is that it documents how/why certain dependencies are necessary, by associating them with the particular modules that use them.
Phase 2: Affect on runtime behavior
This second part involves more tinkering with composer-internals and may not be feasible, but I'm writing it out as a "cool to have".
Each module's vendor/autoload.php file shall only try to load assets that are referenced (directly or transitively) via its deps, require, or require-dev sections.
This behavior should extend to composer archive with issue archive sub-command #18 , and affect what assets are present in the vendor folder.
The text was updated successfully, but these errors were encountered:
@DHager I don't understand exactly what you need for this issue, Phase 1+2 is already done exactly this way, the keys are called deps and deps-dev (rename better?) and the autoloader is adjusted to include only the dependencies that are listed in fiddler.json.
We could indeed warn about unused dependencies from composer.json, but that is more a nice to have.
Ah, my mistake, I was testing with several modules whose fiddler.json settings contained stuff like "symfony/debug", and when I changed them to "vendor/symfony/debug" I must have missed one, so I was still getting a "non existant package" error.
Currently you have to list all external dependencies together in the shared
composer.json
, however this does not make it clear what the needs are for any individual module (subfolder), and may cause the inclusion of unnecessary dependencies when only certain modules are desired.Phase 1: Configuration
composer.json
.fiddler.json
file shall support two new sections,require
andrequire-dev
. These sections contain an array of strings, where each string is the name of a composer-dependency that it relies upon.require
dependency in afiddler.json
must have a direct corresponding entry in therequire
section ofcomposer.json
.require-dev
dependency in afiddler.json
must have a corresponding entry in therequire-dev
orrequire
sections ofcomposer.json
.require
orrequire-dev
entry incomposer.json
that does not have any corresponding entry somewhere in at least onefiddler.json
file should cause a warning message, since it may indicate an unnecessary or unclear dependency.The benefit of this feature is that it documents how/why certain dependencies are necessary, by associating them with the particular modules that use them.
Phase 2: Affect on runtime behavior
This second part involves more tinkering with composer-internals and may not be feasible, but I'm writing it out as a "cool to have".
vendor/autoload.php
file shall only try to load assets that are referenced (directly or transitively) via itsdeps
,require
, orrequire-dev
sections.composer archive
with issue archive sub-command #18 , and affect what assets are present in thevendor
folder.The text was updated successfully, but these errors were encountered: