Open klaussner opened 7 years ago
The required npm packages would have to be installed as devDependency
Wouldn't it be better if it would check both dependencies
and devDependencies
so this could be used by "normal" packages and not just build plugins?
Good point! Then it would be a replacement for checkNpmVersions
, I think.
I guess the question becomes, should we just be using checkNpmVersions
instead or do we need this in Meteor?
I guess it would be nice to have both peerDepends
and devDepends
alongside depends
.
The problem is that build plugins can't access packages from node_modules
. checkNpmVersions
just reads the package.json
and compares version numbers, so that doesn't help in this case.
What would devDepends
be used for?
What would devDepends be used for?
For creating a meteor package that depends on linting/project meta stuff maybe? I didn't really have a use-case I was just thinking out loud.
Because of this restriction on Meteor, I had to fork @klaussner 's package svelte:compiler
just so I can keep my app's version of svelte
in sync with the compiler's version - and also just to keep the version up to date!
I created a PR for meteor-svelte which uses findUp
to grab the package.json
file (that part was already in there!), and figure out where the node_modules
directory is, then loads specific packages it finds in package.json
from node_modules
(svelte
in this case).
The technique could be turned into some useful utility method (maybe Npm.peerDepends
).
It would be helpful if build plugins could depend on npm packages from the application's
node_modules
. That would have two advantages:Maybe this could be implemented as an API like this:
Npm.peerDepends
would be similar toNpm.depends
but instead of causing the packages to be bundled with the build plugin, it would check if the installed versions match the given version constraints and output an error if they don't. The required npm packages would have to be installed asdevDependencies
on the application level: