-
Notifications
You must be signed in to change notification settings - Fork 3k
peerDependencies (plugins) #1400
Comments
What about taking a page from
and then have something like
|
Yeah, a flag to install them automatically would be good. Then at least it'll feel like a separate step. However, I'd really like to make the installation actually fail if they're missing, and require the use of |
That makes sense; A |
Perhaps |
Additional discussion is at #930 |
@isaacs Any progress here? What can I do to help? |
Ping. We've run into this while working on plugins for Chai. The plugins need to be able to specify that they will only work with (e.g.) Chai >= 1.0.1. |
Ditto. We're trying to get plugins for mojito going as well. The only thought we'd had so far was to have the plugin specify the host (i.e., express, mojito) as an "engines": {
"mojito": "0.3.x"
} Since (I believe) NPM doesn't check the engines (like |
Sorry, yeah, just read #930. As for discoverability, mojito right now walks the app's |
@drewfish Cool. Anyone on the mojito team up to taking on implementing this? |
@indexzero, @isaacs I'd be happy to give this a shot over the weekend. I'd implement the proposal from the OP without the parenthetical for point 1 and without install-by-default-if-missing. Sound good? |
@domenic Sounds good. A couple of things:
|
@indexzero by the parenthetical I meant
Is that |
@domenic No. I misunderstood. Look forward to seeing what you put together :-D |
Sweet! Have been wondering about this too. (And like @drewfish, used |
👍 Totally support this effort, it would be great for plugins. |
I've needed this feature for a long time. Going to give it a shot. |
Regarding point 3: does that really need addressing? Isn't it required to list things in Also re: install by default if missing, I would be wary. Mostly because plugins often share the same state of the parent by |
@indexzero no, it's waiting on npm/read-installed#6, which has a review comment I need to take care of. You can see the installation code here, but it's not really ready to be a proper PR until I have a version of read-installed I can work with. It probably also needs a new test to take care of the review comment. |
Once we have Let's say I have an application that uses Unfortunately, it doesn't seem that easy to robustly locate the package's containing node_modules folder within the app. For one thing, the package may have been symlinked in there, using Thoughts? Apologies if this seems a tad off-topic, but it seems to me that it's part of a complete "we have plugin support" story, so it'd be good to think it through before we commit to a peer dependencies mechanism for npm. |
@mfncooper this is something we've considered for Ender. I'd like to be able to scan all accessible modules and see if any are defined (somehow, something in package.json I suppose) as Ender-compatible plugins to extend the core CLI functionality. Having to discover the current node_modules directory and perhaps the global one(s) is probably not the most robust method and it'd be neat to have a way to get npm to help us out. I think Grunt is even more of a candidate for this kind of thing at the moment though. |
Sweet. This will be really useful for abstracting out components out of https://github.com/bevry/docpad Currently we have our own plugin loader that checks the plugin's package.json file and scans the engines and verifies them ourselves. https://github.com/bevry/docpad/blob/master/src/lib/plugin-loader.coffee#L133-L136 and https://github.com/docpad/docpad-plugin-livereload/blob/master/package.json#L31-L34 - so what @drewfish suggested. However, having this |
Is there any work ongoing with regards to the question @mfncooper raised; an |
@gregerolsson I think the point @mfncooper raised is not terribly relevant to our current peer dependencies implementation. The idea of a host package auto-discovering its plugins is not really npm's responsibility IMO. Although, if someone wanted to write something that automatically crawled siblings, inspected their That said, if there are issues related to $ cd b; npm link; cd ..
$ cd a; npm link; cd ..
$ cd x; npm link a; npm link b |
Right, the problem is actually with Node (module.js) when you only link We have an Express-based host application that depends on a bunch of smaller "mountable" Express-apps that we develop ourselves as reusable packages. These apps peerDepend on Express (and a few others) that they expect the host application to provide. And if we need to make changes to an "app" we just Again, we might be doing things the wrong way here. |
I agree with @domenic that the auto-discovery code isn't part of npm's purview. I have working code that includes dealing with BTW, @domenic, did that blog post happen? Link, please? |
@mfncooper Yep, the blog post happened. http://domenic.me/2013/02/08/peer-dependencies/ |
@gregerolsson nice gist, that does explain the problem. It seems like a limitation of how Oh |
Is there a |
@kenany Thank you, I see why I'm struggling to get versions to work as I wish when using a github URL as my installing version...I guess you can't have versioning unless you publish to |
If you want to make This is a unfortunate overhead.. Unless people would recommend |
Yeah, you definitely should not use peerDependencies for a flat dependency tree; that is going to break a lot of things. They are meant for plugins, not artificially flattening your dependency tree. Use |
Yes. I'd rather see it done automatically though. |
I know it's not meant for that but it seems the only way to create a flat dependency tree, I've added |
Flat dependency trees are not inherently virtuous; npm doesn't want to support them just to keep the files flat. Non-duplicated dependencies do have independent virtues, though, so npm does put in work to make that possible. Peer dependencies are pretty unrelated to this whole thing though. |
Sorry @domenic, I meant non-duplicated dependencies, we don't want to send the same dependency version to the browser twice that would be a performance issue as far as I'm concerned but two versions of the same dependency might be OK, at first I was against it but I can see that it could have its uses. It gives the developer time to verify the package that depends on the old version works on the new one and then upgrade or if not fix the issues and then upgrade in a new release. You would need a custom ES6 module loader though that understood |
I mean, any complex web app would probably end up concatenating all its modules into a single file anyway, at which point you're best off using browserify :) |
I wonder if this practice will go away with SPDY adoption... |
@domenic For development too? You'd want F5 reload capability so I guess you use @rlidwka I would love to move away from these tools and rely on the platform instead, I've had some problems with my SPDY tests but I haven't spend much time on them. I had them working up to 100 files pushed but then the browsers hit their max push resources limit and so I tried to push 100 files per request but that seemed to totally fail as the browsers requested files that I had already pushed... |
New package.json field,
"peerDependencies"
Just like
"dependencies"
hash, but:family
(at the same level or higher) as the package. (If the package is thetop
target, and not global, then install as normal deps, maybe, just for testing/development purposes?)--force
flag is set.This enables express middleware and other plugin-type things to specify that they depend on a certain version of express being in-play, but not bundled underneath them.
Open questions:
Should peerDeps be installed by default if missing? Leaning towards no, since this brings up all kinds of cleanup issues on uninstallation.
The text was updated successfully, but these errors were encountered: