@vscode-scoped npm packages

[connor4312]

Historically we've published VS Code-related npm packages with the vscode- prefix. This has a few downsides:

• Contributor access needs to be managed individually. Contributors need to be manually removed from packages when they leave the team, and it's possible to lose access to packages. This has happened in the past, and multiple maintained packages only have a single maintainer.
• We cannot see or enforce 2FA for individual packages.
• It's hard for users to know what are "official" VS Code packages, and easy for others to typo-squat

These would be solvable by moving packages to the Github Package Registry which has a more advanced access model. However this requires all consumers of the packages to manually edit their .npmrc files in order to install packages, which can be a headache in CI and for inexperienced Javascripters.

The other solution is to use npm organizations. We have created the @vscode organization on npm, and we recommend that published packages eventually move to be @vscode-scoped. This can be done in a non-breaking way by keeping the old package on npm and publishing new versions of the package under the @vscode organization. Moving a package involves:

1. Messaging me your npm username if you do not have access to the npm org
2. Renameing the package in your package.json, and then running npm install or yarn again to update your lock file.
3. Running npm publish --access public
4. Optionally running npm deprecate vscode-package-name "This package has been renamed to @vscode/package-name, please update to the new name"

Here are the packages we published which are vscode-prefixed. If these are still in maintained and in use, particularly if they're consumed by the public, consider moving them under the @VScode org:

• generator-code cannot be renamed due to how yeoman discovers packages
• vscode-test-web => @vscode/test-electron @connor4312
• vscode-codicons => @vscode/codicons @misolori
• vscode-uri => @vscode/uri @jrieken (no plans to migrate)
• vscode-json-languageservice => @vscode/json-languageservice @aeschli (no plans to migrate)
• vscode-css-languageservice => @vscode/css-languageservice @aeschli (no plans to migrate)
• vscode-html-languageservice => @vscode/html-languageservice @aeschli (no plans to migrate)
• vscode-json-languageserver => @vscode/json-languageserver @aeschli (no plans to migrate)
• vscode-web-custom-data => @vscode/web-custom-data @aeschli
• vscode-languageserver-textdocument => @vscode/languageserver-textdocument @dbaeumer (no plans to migrate)
• vscode-chrome-debug-core => @vscode/chrome-debug-core @roblourens (Deprecated)
• vscode-chrome-debug-core-testsupport => @vscode/chrome-debug-core-testsupport @roblourens (Deprecated)
• vscode-ripgrep => @vscode/ripgrep @roblourens
• vscode-cached-file-search-provider => @vscode/cached-file-search-provider @roblourens (Deprecated)
• vscode-debug-logger => @vscode/debug-logger @roblourens (Deprecated)
• vscode-ripgrep-dynamic => @vscode/ripgrep-dynamic @roblourens (Deprecated)
• lsif protocol packages -- should these be under the vscode org even though they're not vscode specific? @dbaeumer (no plans to migrate)
• vscode-languageserver => @vscode/languageserver @dbaeumer (no plans to migrate)
• vscode-languageworker => @vscode/languageworker @dbaeumer (no plans to migrate)
• vscode-languageserver-types => @vscode/languageserver-types @dbaeumer (no plans to migrate)
• vscode-languageserver-protocol => @vscode/languageserver-protocol @dbaeumer (no plans to migrate)
• vscode-nls => @vscode/nls @dbaeumer (no plans to migrate)
• vscode-nls-dev => @vscode/nls-dev @dbaeumer (no plans to migrate)
• vscode-jsonrpc => @vscode/jsonrpc @dbaeumer (no plans to migrate)
• vscode-emmet-helper => @vscode/emmet-helper @rzhao271
• vscode-windows-registry => @vscode/windows-registry @sbatten
• iconv-lite-umd => @vscode/iconv-lite-umd @bpasero
• vscode-telemetry-extractor => @vscode/telemetry-extractor @lramos15
• vscode-textmate => @vscode/textmate @alexdima (no plans to migrate)
• vscode-debugprotocol => @vscode/debugprotocol @weinand
• vscode-debugadapter => @vscode/debugadapter @weinand
• vscode-debugadapter-testsupport => @vscode/debugadapter-testsupport @weinand
• vscode-js-debug-browsers => @vscode/js-debug-browsers @connor4312
• vscode-sqlite3 => @vscode/sqlite3 @bpasero
• vscode-jupyter-lsp-middleware => @vscode/jupyter-lsp-middleware @rebornix
• vscode-textbuffer => @vscode/textbuffer @rebornix
• vscode-extension-telemetry => @vscode/extension-telemetry @lramos15 @sbatten

[bpasero]

@connor4312 the list seems out of sync with our repository, none of my modules are used anymore, though some are missing like iconv-lite-umd and windows-mutex. I suggest to review our dependencies of package.json again, some might not start with a vscode prefix.

[connor4312]

I enumerated this list by searching npm. If there are packages that are no longer in use/maintained, feel free to just check them off.

[bpasero]

Maybe people should fill in the modules they own individually, I am sure there are more not so easily discoverable.

[rzhao271]

Done. vscode-emmet-helper -> @vscode/emmet-helper
I was getting 404 errors while trying to publish the package, but running npm login again worked.

[bpasero]

Before renaming any of the node modules that are used by embedders in web, I would wait for #125643 to land and be adopted.

[aeschli]

Sorry, I think we should discuss whether the benefits really outweigh the costs. I agree with the downside listed above. That said, none of them has caused real problems so far. The migration is work, for us and for the users of our node modules. And we end up in a world where the old modules still are around, referenced and mentioned in code, documentation, samples, etc.
Unless there's organizational pressure, I'd suggest to not do it for existing popular node modules. Our users (and us) will be thankful for one swirl less.

[connor4312]

We have had some issues, e.g. we still need to recover vscode-dts since no one can publish it right now. But yes the migration is a suggestion, not a mandate. We should publish new packages under @vscode when relevant, but use best judgement to consider if and how you want to move packages over. Also, as mentioned, the migration can be very gentle since the old packages can exist and even be "dual-published" for a period of time, and they'll remain for existing consumers even after that no longer happens.

[connor4312]

@aeschli @dbaeumer @roblourens @alexdima @weinand @lramos15 @sbatten Please try to look into your packages this iteration. Let me know if you have any questions or need help 🙂

[dbaeumer]

@connor4312 I think the current approach of some doing this and some not is the worst we can do for the community. If we think this is something that we want to see happening then we should do the following:

• move all packages that are still in use to the vscode namespace.
• publish a last version of the non vscode package and add some sort of warning that the name changed
• write a blog post that we did this explaining why and how users should move forward

[dbaeumer]

I had a longer discussion with Martin and he pointed out the swirl he had doing this for a simple not very used npm package. So I am actually more in favor of not doing this at all given the fact that this has no benefit for the user.

[connor4312]

I think of it as analogous to Github organizations, where using microsoft for our repos gives packages we officially maintain recognition (right now even enumerating the packages we 'own' is a very manual and lossy process) as well as the ability to manage access ((there've been multiple times in the past where people left the team but were still maintainers on various packages months or years later) and organization policies (enforcement of 2FA on npm packages is useful.)

• publish a last version of the non vscode package and add some sort of warning that the name changed
• write a blog post that we did this explaining why and how users should move forward

Small note that publishing a last version is not required, as using npm deprecate can add a message to existing versions. Also, if the deprecation message has a notice to update to the @vscode/* package name, I'm not sure any additional blog post is necessary, since the instructions to move forward are self-contained. Perhaps referencing this issue is sufficient.

I had a longer discussion with Martin and he pointed out the swirl he had doing this for a simple not very used npm package.

@aeschli can you share your learnings here? I migrated what's now @vscode/test-electron and did not have any resulting noise.

[aeschli]

I migrated vscode-test-web to @vscode/test-web and while vscode-test-web was only used by a limited group of people it I had to ask several of them to update when seeing bugs surfacing reported related to the deprecated version.

Users are just not very eager to update dependencies unless there's an urgent need for it. I think that's also fully understandable, and I can relate.

Consequently, the old package will stay around. That adds complexity and can be a cause of confusion. And, we still need to manage the access to the old package as we did before.
In the end we just created more work for us and the users.

Look at https://www.npmjs.com/package/vscode-test. It's still used as always.

I suggest we invest in tooling on our side that ensures that all node-modules are owned by us but follow certain guidelines.
A minimal number of maintainers and check that it also has a microsoft-admin user. The product catalog from @lszomoru and @sbatten can serve as input.

New packages and packages mainly used by us should switch to the new namespace.

[connor4312]

If you're renaming a package required by VS Code core, it's come to our attention that some consumers attempt to require these packages directly in their extensions. I've added an aliasing system to prevent this from breaking extensions. If your package is one of these, please add the appropriate alias here as you update the package.json:

vscode/src/vs/workbench/api/common/extHostRequireInterceptor.ts

Lines 97 to 104 in 3d1576a

	/**
	* Map of aliased internal node_modules, used to allow for modules to be
	* renamed without breaking extensions. In the form "original -> new name".
	*/
	private static readonly aliased: ReadonlyMap<string, string> = new Map([
	['vscode-ripgrep', '@vscode/ripgrep'],
	]);

@sbatten @alexdima @chrmarti

[connor4312]

Looks like we cleared all the ✅ , thanks for moving your packages! 🙂