Concerned about the willingness of others to patch their typescript

[craigphicks]

In order for third party developers to use a transform developed with ts-patch'ed typescript, they will have also have to ts-patch their typescript. However, it is possible that some other parties will balk at altering their typescript.

It might expand the reach of ts-patch if 'tsc-patch' and 'ttserver-patch` were also made available as front-end interfaces depending upon plain typescript - as I believe was the case for ttypescript (using ttsc and ttsserver).

More usage could mean more developers eventually willing to go the "patch" path permanently.

[nonara]

it is possible that some other parties will balk at altering their typescript.

Agreed. When I initially created this, I did it because the instructions for setting up ttypescript were incredibly long and varied for many different libraries which consumed typescript (webpack, ts-node, etc). I also considered that there would be a time drag on doing in-memory patching each time it was run.

Since that time, the instructions got a little more simple and seem far more justified. I also am not a big fan of the idea of directly patching a node_module, as this point. The biggest reason for this is that yarn really isn't a fan. ☺

I've spent the last year or so thinking on how we might redesign it to get the best of both worlds, in addition to offering a more complete plugin system which can allow for custom patching of TS and multiple patches, language service plugins, and transformers in a single package.

I'm glad to report that development is now underway. You can follow that in this discussion and watch the development in the v2 branch.

Viz a viz modification, we will not directly modify node_modules. We will, instead have a cache folder, which houses modified copies. Plugin config and corresponding TS installation will be monitored and cache will be intelligently updated automatically, as changes are needed.

It will also offer setting up shell aliases (ie. re-assigning tsc to a specific installation) and making use of yarn / npm package aliasing, so you can cause the module identifier typescript to resolve to your cached dir.

Feel free to join in the discussion with any suggestions!

[craigphicks]

So the cache can be under the project folder rather than in node_modules? Great work!

I noticed that with vscode the language server can be specified on a per project basis by setting the path to typescript lib, e.g.,

{
  "typescript.tsdk": "./node_modules/typescript/lib"
}

which I am sure you already familiar with, but I post anyway, for the record. So it will be easy to switch.

[nonara]

So the cache can be under the project folder rather than in node_modules? Great work!

Correct! With modern innovations in yarn and npm, we can make use of package aliasing and symlinks to have everything wired up nicely.