You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[RRFC] improving the workspaces symlinking experience #556
Personally as I began working with workspaces, one of the most confusing concepts was how to actually access one module from another. I've also heard this from other folks - extremely skilled engineers - I've talked to who were trying to pick up workspaces, prior to me using them. Upon reaching out to folks that I think most others wouldn't have available to them, I was able to understand that the modules were symlinked from node_modules. Great!
The one pain point with that is that it's not entirely obvious what the "correct" way to do this is. Sometimes it works magically, but other times it doesn't. This seems to be because this symlinking feature is hidden behind npm install, either at the root or in the new workspace you want to add (npm install -w myspace).
I'd like to request that this be improved in some way. Here are the ways I've thought of:
triggering symlinking more often: when i npm i -w lol, symlink lol. I assume this has to do with Arborist, so I'm not sure what the simplest way to do this is but ideally taking whatever path has the least perf impact would be ideal.
manually triggering symlinking: I can think of cases where a manual trigger outside of npm install might be useful (people who want to manually do everything, external tooling that does it but not the linking). npm ws link or something like that.
Example
How
Current Behaviour
npm init -w myspace
npm install # it's unexpected that I have to do this!
Desired Behaviour
npm i -w myspace # automatically links on init!
npm ws link # links all workspaces!
npm ws link myspace # just links myspace!
@bnb I'm also finding a very similar issue in npm version -w myspace <version> in which users expect the references to that workspace to be updated across dependents.
I believe that there's a very good DX argument here to start running reify at the end of these commands that (when run in the context of workspaces) will cause differences in the installed tree.
Activity
ljharb commentedon Mar 16, 2022
"linking myspace" is a very old-fashioned phrase
I think
npm ws link [foo]makes a ton of sense.ruyadorno commentedon Mar 16, 2022
@bnb did you mean
npm init -w myspaceinstead ofnpm i -w myspacein the current/desired examples?bnb commentedon Mar 16, 2022
yes fixed :)
ruyadorno commentedon Mar 17, 2022
@bnb I'm also finding a very similar issue in
npm version -w myspace <version>in which users expect the references to that workspace to be updated across dependents.I believe that there's a very good DX argument here to start running
reifyat the end of these commands that (when run in the context of workspaces) will cause differences in the installed tree.feat(version): reify on workspace version change
feat(version): reify on workspace version change
feat(version): reify on workspace version change
feat(version): reify on workspace version change (#4588)
bnb commentedon Apr 18, 2022
going to close this since it's been implemented :)
feat(init): reify on init new workspace
feat(init): reify on init new workspace
feat(init): reify on init new workspace
feat(init): reify on init new workspace (#4892)