-
-
Notifications
You must be signed in to change notification settings - Fork 0
peerDeps? #1
Comments
Nah, peerDeps is a mess. It's also most likely being removed eventually: npm/npm#5080
Have regenerator as a direct dependency if you need it: |
peerDeps has undesirable edge cases, but until npm has a better way to support plugins, I think it's good enough. Lots of other plugins use it fine. It would be a bigger problem to install regenerator as a direct dependency, as I now have two versions, and both could be wildly different versions! I'm open to options other than peerDeps, like not even listing the dependency, but I don't see how it's not far worse to have 2 different versions installed. |
Why do you need this? What's the use-case for needing this plugin and require the same version of regenerator directly? |
It's core to how regenerator works: it has runtime that I need to import in node. I need to do |
So you use gulp-regenerator to transpile your Node code and then in that code require the runtime? If so, couldn't you just use the https://github.com/sindresorhus/gulp-regenerator#optionsincluderuntime option? |
If I did that a copy of the runtime would be prepended on every single node source file, which is not desirable at all (not to mention breaks semantics if the runtime depends on any global state). |
Ok, it does look like the "right" way to do it is to keep this as a dependency, and after installing plugins run |
Should this use a peer dependency on regenerator instance of a normal dep? This makes it so that if I need to require regenerator, I have to do
require('gulp-regenerator/node_modules/regenerator')
, and generally makes it hard to work with other stuff. Plugins should usually use peer deps. What do you think?The text was updated successfully, but these errors were encountered: