Cli: [Question] documentation for phase 1 of workspace support in npm 7?

[orzechowskid]

Current Behavior:

running npm install in my top-level workspace does not seem to create a node_modules directory in my nested workspace.

Expected Behavior:

not sure! I am using npm@next-7, in which "phase 1" of workspace support has been added according to this blog post, but I'm unable to find documentation as to what specifically has been done and what is still outstanding. Being pointed to documentation (or being told that none exists yet!) is the main goal of this issue.

Steps To Reproduce:

1. create a test directory: $ mkdir root; cd root
2. create a root package.json file and add a dependency: $ npm init -y; npm install --save lodash
3. create a directory for a nested workspace: $ mkdir -p packages/foo
4. add workspace support to the root package.json: "workspaces": { "packages": [ "packages/*" ] }, as described by the RFC
5. create a package.json file for the nested workspace and add a dependency: $ cd packages/foo ; npm init -y; npm install --save express; cd ../..
6. remove all node_modules directories: $ find . -name 'node_modules' | xargs rm -rf
7. run npm install in the root workspace: $ npm install

at this point, no node_modules directory is present in the nested workspace.

Environment:

• OS: Ubuntu 20.04.1
• Node: v14.9.0
• npm: 7.0.0-beta.8

thanks for any help you can provide!

[KilianKilmister]

I discovered it while debugging something in Arborist: the paths added to the namespaces field (takes standard globs) will be symlinked to the root node_modules folder, and commands like npm install run in the root package will cascade through the workspace packages.

that's what i know so far. theres probalby more

[orzechowskid]

that's what the RFC says should happen, yes. and that seems to be the case if package-lock.json in the root workspace contains a packages field. following the steps above does not create such a field.

[KilianKilmister]

@orzechowskid you have to check in node-modules/.package-lock.json. it's not in the other one

[ruyadorno]

hi @orzechowskid! In the RFC page you linked originally there is an example showing the expected behavior (installing deps of workspaces into top-level node_modules folder) which is actually quite similar to your example 😊

Here's the result example as taken from the RFC, (you can see it here in its context):

$ tree
.
├── package-lock.json
├── node_modules
│   ├── lodash
│   ├── libnpmutil -> ./core/libnpmutil
│   ├── workspace-a -> ./packages/workspace-a
│   ├── workspace-b -> ./packages/workspace-b
│   ├── workspace-c -> ./packages/workspace-c
│   └── react
├── core
│   └── libnpmutil
└── packages
    ├── workspace-a
    ├── workspace-b
    └─ worspace-c
        └── node_modules
            └── [email protected]

In the example above, it's possible to have a ./core/libnpmutil/index.js that contains a require('lodash') (so that you can cd ./core/libnpmutil and node index.js from there) and that require('lodash') is going to work as expected, this is possible due to Node.js own module resolution that you can dig more in case you're curious about it.

Let me know if this is helpful enough and feel free to close the issue if that's the case 😄

[peterjuras]

I ran into a similar issue and I think it is related to #1762. The new npm configuration that contains the workspaces field appears to be ignored for me if there is an existing lockfile and the issue is that you are running npm install lodash before adding a workspaces field. (Although I consider this a bug)

I got npm@7 to correctly create a workspace by first ensuring that all folders & package.json files were configured correctly, removing all node_modules & package-lock.json files and then running npm install in the workspace root.

[orzechowskid]

I think it was a mistake on my part to include an example in my original report when all I was really looking for is documentation. I was attempting to follow the issue template and tried to make clear what I was asking for, but it seems like I did not do a very good job and for that I apologize.

if I can rephrase: how do I find out which features of npm workspaces are supported in the latest npm 7 betas and which are not, so I can file bugs against features that are supposed to work and be patient regarding features which are not?

[ruyadorno]

if I can rephrase: how do I find out which features of npm workspaces are supported in the latest npm 7 betas and which are not, so I can file bugs against features that are supposed to work and be patient regarding features which are not?

oohh I see 😅 sorry I was really confused by the original post and replies.

so the one important thing to note here is that we still have some test and documentation work to wrap up after we're done with the beta 😁 so for now the best documentation available on what is supported really is that approved RFC that you linked originally. Anything not in there you may assume to not be supported for now (note: we already have an ongoing follow up RFC open to get feedback on implementing more workspaces features).

Hope this is more helpful now! 😄 Thanks for reaching out and helping us clarify that!

[orzechowskid]

ahh, that makes sense, thank you. I will stick to what's in the RFC for now, and follow along with discussions in progress. thanks again.

[mccxiv]

For people reaching this via search engine, this RFC is the only documentation available at the moment...

[limal]

I fell like the current documentation (RFC) is really lacking in real-life examples. If you're stuck like I was yesterday you can learn on my misconception of the npm's workspaces (they are not like yarn workspaces at all) and how to actually use them in my article Simplify your monorepo with npm 7 workspaces .