Proper way of patching tsserver?

[NickSeagull]

Hey, thanks for this amazing project, it is super useful!

I'm currently working on a program transformer to implement custom desugaring. I've made it to compile properly and generate code that typechecks, etc.

Now, for this transformer to be useful, I was wondering if there would be a way to patch tsserver without having to create a special language server. The idea of this transformer is to be part of a framework, so it would include ts-patch by default in all projects, but making the users have to install an additional LSP plugin wouldn't work. Any guidelines here?

On the other hand, the other possibility is implementing the desugaring in a TypeScript fork, but that comes with it's own challenges, like having to maintain parity with upstream.

Thanks!

[nonara]

Thanks for the kind words, Nick!

The conventional way to go about doing something that alters both compilation and LS behaviour is to write a LS plugin in addition to your transformer.

In v2, I plan to allow bundling LS + transformers into the same package, requiring only a single config line. Unfortunately, it's not ready yet.

You can still accomplish the same, however. The only downside is that you'll need two lines in the config. But, you can have both the LS plugin and any other transformers in the same module, or even the same file, using the import property to specify the correct export.

ie:

{
  "compilerOptions": {
    "plugins": [
      // Assumes programTransformer is an exported function
      { "transform": "my-plugin", "import": "programTransformer", "transformProgram": true },

      // Default export will be LS plugin
      { "name": "my-plugin" },
    ]
  }
}

To make it easy, you could create a small init cli script which would add the lines to tsconfig.

I do agree that forking TS isn't a good idea. Too much to keep up with. Another option is to fork ts-patch and add logic to auto-inject your language service plugin and optionally directly patch Program with what you need.

Something to keep in mind — another feature v2 will have is the ability to add custom patches to your plugin module, which would allow you to write your own logic to insert into the compiled TS libraries. Whatever you write today, with those details in mind, you can build it in a way that should be able to roll directly into the official TSP api in the future.

For now, if it were me, I'd probably go with the first option. At any rate, good luck with it!

[NickSeagull]

The first option looks feasible and possible, thanks!

Regarding writing an LS plugin, I understand that it will be patched, so my code would be patched on top of the default TS LS plugin behaviour, or I have to "fork" the existing tsserver?

EDIT: I just found this repo that might server for me as a starting point

[nonara]

A LS plugin is natively supported by TS, so no patch necessary. The "patch" part of tsp is adding the ability to provide transformers in the tsconfig plugins section.

If you look into language server plugin examples, you should get a good idea of how to move forward.