Handle renamed packages (i.e. `babel-core` -> `@babel/core`)

[debuglevel]

Just a thought, because implementing this might not be too easy.

There are package upgrades which are not picked up because at some point scopes were introduced at npmjs.org (i.e. babel-core was moved to @babel/core).

Unfortunately, my current knowledge about the javascript/nom/node ecosystem is rather limited -- so my ideas might be completely unrealistic.

1. Do these renames usually follow a certain pattern? i.e. could a heuristic like in babel-core -> @babel/core be applied? (But that would introduce guesswork and magic into dependency-time-machine. Not a big fan.)
2. Is there some "these packages were renamed from this to that"-database which could be used?
3. The developer could create a local database about the package renames. dependency-time-machine would have to threat merge versions of those packages and handle the renaming at some point. The database could e.g. look like this:

babel-core, @babel/core

"renames": {
   "old": "babel-core",         "new": "@babel/core",
   "old": "babel-preset-env",   "new": "@babel/preset-env",
}

But maybe this issue is just a bad idea, because such a package rename might require manual adjustments in a lot of other files, too (and hence the --test-script would fail anyway). Feel free to close this issue in this case 😅

[trevorlasn]

@pilotpirxie This has potential!

[pilotpirxie]

Hi @debuglevel ! Thanks for your suggestions.

Do these renames usually follow a certain pattern? i.e. could a heuristic like in babel-core -> @babel/core be applied? (But that would introduce guesswork and magic into dependency-time-machine. Not a fan.)

This would give possible security issues as it would be implicit, and someone could take the organisation name to spread malware packages.

Is there some "these packages were renamed from this to that"-database which could be used?

I'm not aware of any.

The developer could create a local database about the package renames. dependency-time-machine would have to threat merge versions of those packages and handle the renaming at some point. The database could e.g. look like this:

Instead of package developers, it could be done inside dependency-time-machine as "known renames". With the last version of a certain package and continuity as another with a specific version. This would allow us to keep that in a central place and lower the chance of spoofing renames.