How to improve extension author experience dealing with vscode- to @vscode npm module change

[Tyriar]

We're probably going to get a bunch of extension issues like this: Gruntfuggly/todo-tree#595

Should we:

• Add an alias to vscode- when requiring to automatically fix the problem?
• Email extension authors using the modules?
• Write in the release notes of the change?
• Delay the module change an extra iteration?

I know the modules we ship with the product are not "public API", but there are many extensions that do use them.

[connor4312]

We're probably going to get a bunch of extension issues like this

I'm not sure that we are. This is pretty dangerous internal use from the get-go and I would hope is pretty rare.

Add an alias to vscode- when requiring to automatically fix the problem?

This isn't being required, instead it's pulled from the app installation directory: https://github.com/Gruntfuggly/todo-tree/blob/dfd91634b8047614644e5161c588d595b2100ac6/src/config.js#L97-L107 Hence the extra danger and hopeful rarity.

We could preserve the install structure, but the structure of the app folder is not contract we ever intended to have so I dislike treating it as such...

[Tyriar]

I know there are several internal and at least this one using node-pty for example:

https://github.com/mmis1000/Vscode-terminal-tab/blob/a0720ad131664748aecd9915fb3a24ddb42163ab/src/terminal.ts#L6-L21

No one told the author how to do that. It would make sense to me that ripgrep would also see similar usage since searching text is a big use case for extensions and working with native modules in extension also isn't really supported (you can but it's a pain).

[Tyriar]

👀 https://github.com/search?q=getCoreNodeModule&type=code

Just looking at the results page (not digging in when it's not obvious) I see a bunch of uses for keytar, vscode-oniguruma, vscode-textmate, windows-process-tree and node-pty. That doesn't includes the majority of those 7 pages of results, and also doesn't include if the function/mechanism they used was not named exactly getCoreNodeModule.

[connor4312]

If we want to have this be "contract", perhaps we actually expose require.resolve and allow that to resolve internal vscode modules? Then authors could use that instead of depending on modules hackily like this.

[Tyriar]

I kind of like the "soft contract" similar to commands, we're not technically restricted from making breaking changes (I wouldn't want node-pty to never have breaking changes). By using that getCodeNodeModule function, people should know that there are risks, an explicit API would give a signal that it's fine.

Just here, we should be careful about not causing a bunch of broken extensions because we are able to. I'm not saying support vscode-ripgrep forever. We could for example have aliases built-in on the exthost side that logs a warning when used, announce in the release notes of the change, and pull it out 3 months later. Seems like very little effort and much less problems.

[connor4312]

We could for example have aliases built-in on the exthost side that logs a warning when used, announce in the release notes of the change, and pull it out 3 months later. Seems like very little effort and much less problems.

This sounds good. I'll implement this and then link the relevant code here so that, as others migrate their packages, they can add aliases.

[connor4312]

Ok, so one note -- aliasing require is fine which would make getCoreNodeModule work, but todo-tree uses fs.existsSync to check the existence of the file before attempting to require it, which this won't cover. And I don't want to get into patching fs.

[Tyriar]

Yeah I wouldn't do anything there either, but we can catch the common code snippet at least

[connor4312]

It looks like vscode-ripgrep actually exports the rgPath, so a safe alternative would be for them to try { return getCoreNodeModule('vscode-ripgrep').rgPath; } catch {}. I will PR to that effect and create issues on other consumers of vscode-ripgrep.

[connor4312]

Here's the template I posted and all repos I could find who use ripgrep in this way:

• Action needed: update your import of the built-in ripgrep Gruntfuggly/todo-tree#596
• Action needed: update your import of the built-in ripgrep svsool/memo#510
• Action needed: update your import of the built-in ripgrep fabiospampinato/vscode-todo-plus#347
• Action needed: update your import of the built-in ripgrep stef-levesque/vscode-shader#56
• Action needed: update your import of the built-in ripgrep satokaz/vscode-memo-life-for-you#74

And the aliases:

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'],
	]);

[Tyriar]

@connor4312 oh is vscode-textmate and vscode-oniguruma not republished yet?

[connor4312]

Not yet