Open yhatt opened 4 years ago
The same for me too. Extension cannot be package neither by yarn
, nor by npm
.
npm ERR! missing: @babel/parser@7.10.2, required by hegel-language-server@0.0.43
npm ERR! missing: @babel/plugin-proposal-class-properties@7.10.1, required by hegel-language-server@0.0.43
npm ERR! missing: @babel/plugin-proposal-nullish-coalescing-operator@7.10.1, required by hegel-language-server@0.0.43
And so on.
We faced the same issue with gitlab-vscode-extension
, this is my writeup:
The correct npm.ts
implementation discards module version and packages incorrect version of NPM module.
For our extension, this happens because we have two different versions of ajv
in our dependencies. Production code uses v6
and test code v5
. The vsce ls
(and so vsce package
) picks the dev dependency.
The steps that follow can reproduce the issue reliably on gitlab-vscode-exteions
.
git@gitlab.com:gitlab-org/gitlab-vscode-extension.git
git checkout v3.0.0
yarn
ajv@6
by running yarn list --prod
├─ har-validator@5.1.3
│ ├─ ajv@^6.5.5
vsce ls --yarn
will say that we will package the module straight in node_modules
vsce ls --yarn | grep ajv
...
node_modules/ajv/package.json
cat node_modules/ajv/package.json | grep version
"version": "5.5.2",
cat node_modules/har-validator/node_modules/ajv/package.json | grep version
"version": "6.12.2",
The issue is in the flattening logic. When we remove the version and then "ignore" all other versions we are potentially using incorrect dependencies. The only way to prevent this is IMO honouring the dependency structure given by yarn and not attempting to flatten it.
This can result in very subtle and hard to debug issues. Or production incidents
How about always using npm instead of yarn for dependency resolution if vsce was using npm >= v7? npm v7 can generate fully deterministic dependency tree based on yarn.lock
so can expect more reliable packaging.
https://blog.npmjs.org/post/621733939456933888/npm-v7-series-why-keep-package-lockjson
Someone may feel like a bit strange to use npm even if running vsce
with --yarn
, but it would be much better than encountering production incident as like as brought in Marp, GitLab, and Microsoft Azure Logic Apps.
Let me write down I met this trouble in our extension marp-vscode again. How to reproduce:
git clone https://github.com/marp-team/marp-vscode.git
cd ./marp-vscode
git checkout 5f285dc
yarn && yarn package
The following error would output to developer console if tried to activate created VSIX.
abstractExtensionService.ts:717 Activating extension 'marp-team.marp-vscode' failed: Cannot find module 'cssesc'
Require stack:
- /Users/yhatt/.vscode-insiders/extensions/marp-team.marp-vscode-0.15.1/node_modules/postcss-selector-parser/dist/selectors/className.js
- /Users/yhatt/.vscode-insiders/extensions/marp-team.marp-vscode-0.15.1/node_modules/postcss-selector-parser/dist/parser.js
- /Users/yhatt/.vscode-insiders/extensions/marp-team.marp-vscode-0.15.1/node_modules/postcss-selector-parser/dist/processor.js
- /Users/yhatt/.vscode-insiders/extensions/marp-team.marp-vscode-0.15.1/node_modules/postcss-selector-parser/dist/index.js
- /Users/yhatt/.vscode-insiders/extensions/marp-team.marp-vscode-0.15.1/node_modules/postcss-minify-selectors/dist/index.js
- /Users/yhatt/.vscode-insiders/extensions/marp-team.marp-vscode-0.15.1/node_modules/@marp-team/marp-core/lib/marp.js
- /Users/yhatt/.vscode-insiders/extensions/marp-team.marp-vscode-0.15.1/lib/extension.js
- /Applications/Visual Studio Code - Insiders.app/Contents/Resources/app/out/vs/loader.js
- /Applications/Visual Studio Code - Insiders.app/Contents/Resources/app/out/bootstrap-amd.js
- /Applications/Visual Studio Code - Insiders.app/Contents/Resources/app/out/bootstrap-fork.js.
_logMessageInConsole @ abstractExtensionService.ts:663
It can fix by adding --no-yarn
option to vsce command in package
npm-script: marp-team/marp-vscode#178
We have the same problem when publish Vetur. We downgrade to old version for solve this problem at the end.
Any updates on this issue? I have the same problem here, downgrade to 1.76 still seems not to work.
Err, open 2 for years, still not fixed?
Have two dependencies with different chalk
versions:
yarn why v1.22.17
[1/4] Why do we have the module "chalk"...?
[2/4] Initialising dependency graph...
[3/4] Finding dependency...
[4/4] Calculating file sizes...
=> Found "chalk@2.4.2"
info Has been hoisted to "chalk"
info Reasons this module exists
- Hoisted from "@babel#core#@babel#code-frame#@babel#highlight#chalk"
- Hoisted from "@sqltools#base-driver#@sqltools#log#pino-pretty#args#chalk"
info Disk size without dependencies: "44KB"
info Disk size with unique dependencies: "96KB"
info Disk size with transitive dependencies: "188KB"
info Number of shared dependencies: 6
=> Found "pino-pretty#chalk@4.1.2"
info This module exists because "@sqltools#base-driver#@sqltools#log#pino-pretty" depends on it.
info Disk size without dependencies: "56KB"
info Disk size with unique dependencies: "92KB"
info Disk size with transitive dependencies: "184KB"
info Number of shared dependencies: 5
Done in 0.16s.
But only one dependency is present in vsix file:
unzip -l my-extension-0.0.1.vsix | grep chalk
6439 2022-01-18 22:14 extension/node_modules/chalk/index.js
1921 2022-01-18 22:14 extension/node_modules/chalk/index.js.flow
1109 2022-01-18 22:14 extension/node_modules/chalk/license
1195 2022-01-18 22:14 extension/node_modules/chalk/package.json
10774 2022-01-18 22:14 extension/node_modules/chalk/readme.md
3133 2022-01-18 22:14 extension/node_modules/chalk/templates.js
I'm in awe actually, either say that you don't really support yarn or fix it. As right now you de facto do not support yarn, because of this bug.
Think about a simple package like this, developed with yarn 1.22.4:
The creation of extension through
yarn vsce package --yarn
will success, but will fail to activate in VS Code.It would work correctly if created through npm with
yarn vsce package
.I've compared the structure in both of VSIX archives, and noticed the VSIX from yarn has included only a dependency
entities@1.1.2
hoisted from devDependenciess (vsce
->markdown-it@8.4.2
->entities@1.1.2
).Look at the difference of the structure about
entities
package.The extension expects to use a not-hoisted
entities@2.0.0
in dependencies (markdown-it@10.0.0
->entities@2.0.0
), notentities@1.1.2
in vsce's devDependency.In fact, there is not-hoisted
entities@2.0.0
in/node_modules/markdown-it/node_modules
while development even if installed packages by yarn. I suppose the process of packaging via yarn has some wrong.Workaround
An available workaround is just using npm by omit
--yarn
.However, it has not a worth in a few case. The author of extension has to use
--yarn
if usingresolutions
field (only supported in yarn), for resolving some vulnerabilities in deep dependency.vsce package
via npm would throw an error due to the different structure ofnode_modules
between npm and yarn.For example, the following is to fix a vulnerability in deep dependency of Puppeteer v2.1.0 by yarn.
vsce package
using npm will fail by the different structure.Sometimes I've met this trouble in the extension developed by me: https://github.com/marp-team/marp-vscode/pull/35, https://github.com/marp-team/marp-vscode/pull/130#issuecomment-602164173
UPDATE: npm v7 has shipped with support for
yarn.lock
and can generate fully deterministic dependency tree. Just using npm v7 might not need to worry about incorrect packaging.