substitutes property

[jonathanong]

a component can "substitute" another component in a build. this is convenient for forks and different "versions" of components. this is important because you don't want to include multiple copies/versions of a component

substitutes must be API compatible.

ex. if you have a fork, you can replace all copies of the original component with your fork in your build:

{
  "name": "emitter",
  "repo": "jonathanong/emitter",
  "substitutes": {
    "component/emitter": "*"
  }
}

this will handle cases where you don't want multiple copies of emitter included in the build, but want a different emitter, such as one that handles name spaces or something.

you can also substitute older versions of yourself. this tells people "this version is API compatible with these versions", and makes pinning dependencies less of an issue:

{
  "name": "emitter",
  "repo": "component/emitter",
  "version": "1.9.0",
  "substitutes": {
    "component/emitter": ">= 1 < 2"
  }
}

so any builds that include "component/emitter": "1.0.1" will still use 1.9.0 in the build as it's "API compatible", assuming 1.9.0 is already included in the build.

this would also help in discovery with the registry. we could also add similar properties primarily for discovery such as alternatives, extends, etc.

[Swatinem]

so any builds that include "component/emitter": "1.0.1" will still use 1.9.0 in the build as it's "API compatible", assuming 1.9.0 is already included in the build.

👍

[tj]

I don't get it, this is just semver, so we should just support 1.x

[jonathanong]

Actually I'm iffy on the older version thing, but I still think we should support forks and such

[jonathanong]

it's not just semver. it's about minimizing multiple copies and forks of a component. the "just semver" portion is an added benefit, but i actually don't want to document it since people might abuse it.

[tj]

ah i had only skimmed over your description, I see what you're saying. I can't see it working too well in practice beyond simple cases (which probably aren't broken anyway), because for example if you say your thing substitutes 1.x of "foo", and then the author of "foo" goes and bumps to 1.3 with some new features that other modules use, you have to go upgrade yours asap. I like the idea in general but I'm not sure it would get much use or work out that well

[jonathanong]

yeah, so you would have to do substitues ~1.2 of foo or something. i can also see a lot of edge cases that occur like two different modules that substitute the same module.

[tj]

true yeah that as well

[vendethiel]

I kinda like the solution read-components uses, just "overrides" some package dependencies (though one of the main feature is that you can remove some files, like bootstrap's js files, which we don't really need).

My biggest concern with the "substitutes" is that you define it in a component, seems like that's something more app-related than component-related : does that mean if I want some 3rd-party component to use "modella/modella" instead of "component/model" I'll have to fork it ?