Closed sergeykad closed 2 years ago
Yes, create was a bit bolted on to get started, but keeping the current versions for create makes sense.
Generating sensible aliases is very subjective, currently there is some logic to not repeat the module name if the group name ends with it for example, but it is expected that you go in and change the keys to your liking and remove dependencies that are reported but do not need an entry in the catalog. The latter is inevitable because there's no good way to know where a dependency is coming from, e.g. if you declared it or if some plugin is contributing it.
If you have suggestions on how to make the default keys more suitable then let me know.
Updating the actual build files with references from the catalog I consider out of scope for this plugin. There's no good way to do this, except for regexp find and replace and I don't want to go there risking messing up your build files. There might be other plugins that do this that you could apply for this one time conversion.
My suggestion for new keys creation: #15
@hvisser Thanks for the detailed answer. Just keeping the current versions will be a huge help.
I want to use the plugin for migration to the new version catalog, at least initially. Doing it all manually for a few hundred unique dependencies is a bit too much.
Is it possible to implement migration (
--create
) to to the catalog using the currently used dependencies versions? Migrating everything to the latest versions can be problematic in larger projects. The option to generate sensible aliases and replace existing dependencies with catalog references will be also great.