Meta packages #4555

dresende opened this Issue Jan 27, 2014 · 2 comments


None yet
2 participants

I think this is somewhat a nice to have feature.


Have a package that actually is a kind of symlink for another package


I have a database ORM. Not all versions of the drivers used are compatible. Sometimes there are bugs and so, the ORM is suggested to run with a specific version. It would be great if one could create a package to point to the correct package/version.

For example, for a package orm, a meta package orm-mysql could point to a specific version of real package mysql in a specific version. If could even have another name or be switched without people having to know about it.

Since this is used in other package managers I'm assuming there are other good uses for it. My main focus is in this particular example. I'm open to someone who can point me another clean way of doing it.

As a side note, I don't have the drivers as dependencies since people might need just one (and I currently have 4 drivers), so people install the package and then the driver they need.


iarna commented Jun 17, 2016

If I understand you correctly, what you would like is the ability to have a choice of modules that might fulfill a dependency requirement. npm installs are non-interactive which means it would need to pick one arbitrarily to start with. The advantage you gain is an error from npm install or npm ls when no driver is selected at all.

My immediate concern is the complexity this would add to tracking down install errors. What do you do if they can’t install the version the installer picked, but they could install a different one?

If I were solving this problem, my approach would be to pass in the driver module to orm, for example:

var orm = require(‘orm’)
  driver: require(‘orm-mysql’)

Now, if the user failed to install a driver this would be a runtime error, but it would be a runtime error that would show up early in development. This isn’t a case that I see the value in making it an install time error.

As I and the CLI team do not believe the early errors provide sufficient advantage to outweigh the additional complexity that this would add, I’m going to close this issue. Thank you for your time in writing this up.

@iarna iarna closed this Jun 17, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment