Problem
skills: on a dependency is an allow-list. To leave out one skill of a package with many, a consumer has to list all the others. Skills that a later version of the package adds then never arrive in that project, and nobody notices.
Use cases
- An organization ships a shared skill package. One project forks a single skill into its own
.apm/skills/ under a different name and wants the original out of the way.
- A project must not use one skill of a package, for example because a customer does not allow the tool it calls.
Proposal
An exclusion that keeps "everything else, including future skills":
dependencies:
apm:
- git: org/skills
ref: v2.0.0
exclude_skills: [lint]or a negation inside the existing list, such as skills: ['*', '!lint']. Unknown names in the exclusion should fail the install, for the reason described in #3204.
Alternatives
We can generate the allow-list from an exclusion list in a wrapper around apm install, re-computing it on every run. That works, but every consumer who needs this has to build it again. #2413 (declarative overrides) touches a related area.
Problem
skills:on a dependency is an allow-list. To leave out one skill of a package with many, a consumer has to list all the others. Skills that a later version of the package adds then never arrive in that project, and nobody notices.Use cases
.apm/skills/under a different name and wants the original out of the way.Proposal
An exclusion that keeps "everything else, including future skills":
or a negation inside the existing list, such as
skills: ['*', '!lint']. Unknown names in the exclusion should fail the install, for the reason described in #3204.Alternatives
We can generate the allow-list from an exclusion list in a wrapper around
apm install, re-computing it on every run. That works, but every consumer who needs this has to build it again. #2413 (declarative overrides) touches a related area.