Could this be packaged as VS Code add-in?

[octogonz]

I have 100+ projects in my Git repo. It seems a little cumbersome to add this compiler plugin to every single project. Also, I expect the plugin would fail to load unless npm install has been run recently and successfully for each project.

By contrast, VS Code normally uses its own TypeScript engine to analyze source code, without relying on the installation state. That might be an easier way to consume these plugins.

[cancerberoSgx]

Hello, sorry for the late reply - somehow I missed this issue. A couple of notes:

• I made a VS extension that depends on some of these projects: https://github.com/cancerberoSgx/typescript-plugins-of-mine/tree/master/vscode-typescript-refactors. At that time I tried to maintain it but both TS and VS APIs were kind of unstable as well as mu plugins so it's currently broken and I'm not actively maintaining the plugins (more below)

• About your concern, maintaining the code as pure vs-code extension, vs, as a TypeScript compiler plugin, both things have pros and cons. I'm more on the side of keeping it as TS compiler plugin only so it's agnostic to any editor /IDE and, as long as the client editor supports service language protocols the plugins will work out of the box. I verified these plugins to be working in vscode, atom and vim out of the box (the editor's server language takes care of everything.

So I guess I, as a plugin author would prefer maintaining the code as pure TS compiler API, but I understand that other people, as users of a particular editor (I love vscode btw)might be tempted to maintain it as a concrete editor extension since that gives much more flexibility.

I have 100+ projects in my Git repo. It seems a little cumbersome to add this compiler plugin to every single project.

I think that's npm/node.js dependencies are used at least I'm use to declare / instal all my dependencies locally, even devtools, or continuous integration tools (like puppeteer that0s 100mb) . TypeScript compiler API for declare plugins is also like just another npm package.

By contrast, VS Code normally uses its own TypeScript engine to analyze source code, without relying on the installation state. That might be an easier way to consume these plugins.

I'm sorry but that sincerely doesn't make sense to me, there is only one TypeScript engine - the only difference could be the version . BTW if you project has typescript as devDependency (as every project I've seen) - then vscode will use that TypeScript "engine" not its own.

Although you are right regarding that user experience could improve. I think though things are moving to being editor agnostic though - check this: https://microsoft.github.io/language-server-protocol/

About this project, I'm currently not actively working on TypeScript plugins / refactors. I'm maintaining a couple of projects that provides refactor APIs here - but not the plugins ones. I realized TS team is putting more and more effort on providing these kind of tools in tsc itself and althoguh is not well documented users are also contributing with refactor / codefixes to the compiler too. So I decided that if I'm re-taking this task the right way would be contributing to as a TypeScript built-in refactor / code fix.

In the meanwhile feel free to ask/discuss here- perhaps you can use https://github.com/cancerberoSgx/typescript-plugins-of-mine/tree/master/vscode-typescript-refactors as starting point for your extension . If you have any idea I would like to help too - but again, I strongly recommend you to use the minimal vscode API and only for visuals and rely on TS language service API to parse/transform code.

Have a good one, thanks!