Support npm workspaces

[panayot-cankov]

I've just finished moving several VSCode extensions into single monorepo using npm v7 workspaces.

However when the vsce packages using npm (not yarn) it does internally:

npm list --production --depth=99999 --loglevel=error

And that command fails from the workspace to lookup common modules in the root.
I logged an issue at npm
Although I am not sure if this is npm list bug or feature, probably the npm list will have to be extended to look those modules and then maybe some additional work will be necessary in the vsce to package the files correctly.

[panayot-cankov]

On the other hand that part of the RFC:

Make a recursive check that walks up the file system structure and validates if the current prefix is defined as the "workspaces" property of a package.json file of a parent directory.

In case that is so, we can then tweak the internal contexts/variables in such a way that runs the command in the context of the top-level workspace while defining the current working directory as the workspace configuration to be used.

makes perfect sense, and if the npm ls --workspace=myvscodeextension already works (with fixed --prod) it will require zero additional configurations, and will also be backward compatible, as in old repos the npm ls won't look up in the package's parent directories.

npm/rfcs#343

[Jolg42]

Got into this problem as well, the error was not obvious at all. See:

 ERROR  invalid relative path: extension/../../.eslintignore
npm ERR! Lifecycle script `package` failed with error: 
npm ERR! Error: command failed 
npm ERR!   in workspace: [email protected] 
npm ERR!   at location: /home/runner/work/repo/repo/packages/vscode 

The error message here seems to be from the zipping library yazl, https://github.com/thejoshwolfe/yazl/blob/36b2a6a31a32637dca19b34e7b3295378e78a644/index.js#L368

The npm list call can be fount at https://github.com/microsoft/vscode-vsce/blob/main/src/npm.ts#L68

If there were more debug logs, it would have been easier to find out 😓

[51ngul4r1ty]

Any progress on this? I would also like to get VS Code Extensions working in a monorepo and it doesn't work for me. I'm assuming that there's still work needed to fully support npm workspaces?

[xt0rted]

I just ran into this after a few hours of cryptic error messages. I haven't done extensive testing yet but my workaround so far is to bundle with @vercel/ncc just like I do on my GitHub Actions and then package with vsce package --no-dependencies. Since ncc bundles your code and your dependencies into a single file the --no-dependencies flag seems to be a sufficient hack.

[remcohaszing]

I ran into this issue too. But I figured out it's also possble to specify vsce options in package.json.

{
  // …
  "vsce": {
    "dependencies": false
  }
}

[vritant24]

Just ran into this issue, it would great to have this documented.
@remcohaszing 's workaround fixed it for us

[qarlosalberto]

any example?

[remcohaszing]

https://github.com/mdx-js/mdx-analyzer/blob/v1.3.0/packages/vscode-mdx/package.json#L38..L40

[qarlosalberto]

Thanks! But an example not using bundle. I cant use a webpack because I have external binaries.

[remcohaszing]

I found a workaround that allows you to partially include node_modules: mdx-js/mdx-analyzer@ccb7571.

This does break relative links in the readme, so make sure to use only absolute links.

[deribaucourt]

In my case, with vsce 3.1.0, I get this error because there is a workspace in my package.json that is a link to a shared folder.

Error: not a file: /home/deribaucourt/Workspace/yocto-vscode/vscode-bitbake/server/node_modules/vscode-bitbake-lib
    at /home/deribaucourt/Workspace/yocto-vscode/vscode-bitbake/node_modules/yazl/index.js:31:79
    at FSReqCallback.oncomplete (node:fs:200:5)

The workaround doesn't seem to solve it.