Persist local overrides

[theefer]

When jspm installing packages, there seem to be two different kind of definitions that can take place.

The first one, "aliasing" (e.g. jspm install jcrop=github:tapmodo/Jcrop@0.9.12), makes the given package available under an alias by adding a config mapping line to the config.js file.

The second, overrides (e.g. jspm install github:tapmodo/Jcrop@0.9.12 -o '{"main": "js/jquery.Jcrop", "shim": {"js/jquery.Jcrop": ["jquery"]}}'), configures overrides for the original package by altering the package.json file in the jspm_packages/github/tapmodo/... local cache.

My general stance is that dependencies should not be committed to the source tree of a projet (e.g. bower_components, node_modules or jspm_packages), only the dependency definition file should be. In the case of jspm, I assume the good practice would be to commit the package.json, as well as the config.js file to would guarantee locking of versions of transitive dependencies?

So that means the aliasing is also persisted, however the overrides would not be as they are not written to package.json or config.js. Am I missing some way to persist overrides to a source tree?

If not, should the overrides be written to config.js instead? Or else, where?

Currently, I've been adding them to another file that isn't managed by jspm, but that means jspm (and jspm bundle etc) are missing the information.

[guybedford]

Overrides should be included in the jspm registry. That is the level of persistence. Making the workflow of going from testing an override to publishing it is something that I want to work on so that this can be done from the CLI naturally.

Ideally overrides should be sent as PRs to the original repo as well.

Does this workflow make sense? It would be good to discuss ways of refining it.

[theefer]

Just to be sure I understand correctly, by "jspm registry" in

Overrides should be included in the jspm registry

you mean https://github.com/jspm/registry? I guess it makes sense, I'm just worried if that may make it more of an unwanted bottleneck?

For example, it means there is no way to share overrides for a dependency in a project unless they can be added either to the dependency's package.json or to the public but externally managed jspm registry?

This may raise a few issues:

• The delay in getting a fix merged in either could be a little frustrating (some people occasionally sleep).
• I'm not sure if jspm supports dependencies in non-public repos yet, but these would obviously not want to have overrides in the public registry.
• I don't know if there's a case for wanting to use one own's overrides over what is even in the public registry (e.g. main pointing to source vs minimised, etc)?

In short, I think relying on the public registry will work absolutely fine for us currently, but I just want to make sure we think the design through.

Perhaps it felt natural to have the ability to persist overrides the same way it is possible to persist aliases.

[guybedford]

Yes exactly. It is important that when I load a public package from github or npm in jspm, that we can all be sure we are referring to the same thing. Sharing overrides is part of that.

Overrides are there simply to bridge the gap between making something work now and having something work in future.

Typically I would expect that at the same time an override is posted to the registry, the associated package.json update is posted into the original repo. Ideally we wouldn't need overrides at all and everything would be in the original package.json files. Similarly, if there are private repos that you have access to, then you can control the package.json instead of needing overrides.

For response, the idea is to have enough people with commit access to the registry over time zones to always close a PR there within a few minutes. Curated commit access is important to ensure that the overrides make sense for everyone as they are global.

[theefer]

Closing as we agreed to try and use the public jspm registry instead.

[guybedford]

Ok, always happy to discuss process further. Did you consider posting a PR to jCrop itself?

[trusktr]

Ideally we wouldn't need overrides at all and everything would be in the original package.json files

Ideally, but not realistically due to the fact that not all devs will do it, as simple as it even is. F.e. I asked famous to do it, but they didn't want to add "bloat" to their package.json, unfortunately, so even awareness of jspm doesn't mean they'll do it.

+1 for jspm.overrides in package.json.