sorry for the rambling.
Not at all, thanks for taking the time to provide this detailed breakdown!
No (at least not the way we’ve implemented it, which represents the npm 2 non-deduping behavior).
I have been primarily using npm@3, but I also had the mistaken idea that in some cases npm@2 automatically did limited deduping, e.g. when installing from a
package.json with deps that have semver-compatible deps. Thanks for straightening me out about that.
Thanks for those links, I hadn’t seen either of those before. (P.S. I had a bit of trouble at first understanding the scenario in the bug report without the contents of
index.js or looking up
test-a|test-b – was it meant to include a link to a repro or the contents of
Not to sidetrack this too much, but from reading through that issue, it seems to me that maybe the problem is that the semver range syntax isn’t expressive enough. mhils suggesting making something like
^1.0.0 automatically resolve to the latest compatible version. At the moment I’m not sure if that would be a good idea, but maybe it would be a good idea to introduce some kind of operator to the syntax that allows opting in to that. E.g. “^^1.0.0” means the highest compatible version that’s published.
But again, since the way packages “make it in” to a notebook is by you typing require, they need to appear somewhere in the code. We could implement a system like you’ve described though where you just say "I want React x for all my notebooks’, and then we just make a secret note of require(“react”) at that version. We’re also working on a way to select the version of the package visually in the notebook (require(“x”) would show a menu next to it with all the version).
So, obviously I don’t know much about how your system works under the hood beyond what you’ve explained to me, but re: this part…
since the way packages “make it in” to a notebook is by you typing require, they need to appear somewhere in the code
…is that a current implementation detail or an essential invariant? In other words, is there any reason it has to work that way, or it’s theoretically possible to do it another way, like read from a
package.json field that’s part of the notebook to get the top-level dependency and peer dependency packages into the notebook? I guess I’m wondering if that design is based on technical reasons or UX. Just curious.
(FWIW, my thought right now is that I wouldn’t mind entering the top level deps and peer deps into a
package.json field (especially when specifying version), but again I admittedly have only a little experience with the platform.)
I was also wondering, how is that meant to interact with the download feature? I’m reading this from the home page:
All notebooks are just node modules, so you can download them and run them on your own setup with no changes.
Won’t having the version in
require() calls like
require("firstname.lastname@example.org") interfere with that or at least make it more complicated? I tried a quick experiment with downloading and running a notebook with calls like that. (I looked around and couldn’t find instructions for using a download, I just poked around and experimented.) So I did
npm i and stuff installs and I get this message (not sure what it means):
Not installing as notebook: whatever
Then I do
node ./ and I get:
Error: Cannot find module ‘request@2’