Repository navigation
Pre-Compiler Plugin Proposal #38736
Description
Activity
MartinJohns commented on May 22, 2020
Related: #16607
cc Maël Nison (@arcanis) and Lenz Weber-Tronic (@phryneas) - figure this may be interesting to both of you 🥰
(This was to a now deleted comment, so I've edited it up a bit )
WRT this issue I wouldn't expect anything quickly in the short term, what plugin support looks like in TS is still a pretty constant internal debate with strong opinions on many sides of what support looks like. This is why it's shown up a few times on roadmapping but tended to never get past experimental internal demos.
That means we're also real cautious of talking about it because we still don't know what it'll look like, and how we can be sure it doesn't affect perf at the kind of scale that we'd expect to see people use plugins at.
Orta Therox (@orta)
Could you elaborate on what are the performance issues that you are afraid of?
If we assume that transformation to typescript format is a pure function, then we can easily cache it. In this situation, the overhead could be noticeable on the initial compilation, but not in the watch mode (as we rebuild one or a few files). Currently, users use some workarounds to make this work which probably is much slower than we could achieve with plugins. If TypeScript would provide plugins API, keeping the good performance of plugins would be a responsibility of plugin's maintainers - not the TypeScript team. In this context, I don't see performance blockers to move forward but I guess there are other factors that I didn't take into account 😄
Orta Therox (@orta) Do you have any update regarding this feature request? :)
Nope, no updates, other than the move to a node factory API #35282 was long considered a blocker around this
Thanks for the update. I suppose you want to use AST as a format that a plugin should produce. That makes sense - it will be faster. I was also thinking about that but I was afraid you will not want to make AST factories API public.
Is there anything I could do to move this forward? I could implement it if you are busy with other features :)
Afraid not, it is still undecided by the team if and what the extent of plugin support looks like in the TypeScript compiler - plugins systems are not normal for compilers.
Ok, that's a bummer 😞
plugins systems are not normal for compilers.
That's an interesting claim 🤔 https://babeljs.io/docs/en/plugins - babel is made of plugins. https://eslint.org/docs/developer-guide/working-with-plugins - eslint, which performs static analysis, also uses a plugins system. So I would say that at least in the JavaScript community, it's normal.
plugins systems are not normal for compilers.
your claim is not true as there is a lot of compilers that support plugins, most notable one is gcc
- gcc - https://gcc.gnu.org/wiki/plugins
Compiler plugins (or loadable modules) make it possible for a developer to add new features to the compiler without having to modify the compiler itself.
- ghc - https://downloads.haskell.org/~ghc/7.4.1/docs/html/users_guide/compiler-plugins.html
GHC has the ability to load compiler plugins at compile time. The feature is similar to the one provided by GCC, and allows users to write plugins that can inspect and modify the compilation pipeline, as well as transform and inspect GHC's intermediate language, Core.
- scala - https://docs.scala-lang.org/overviews/plugins/index.html
A compiler plugin is a compiler component that lives in a separate JAR file from the main compiler. The compiler can then load that plugin and gain extra functionality.
- rust - https://doc.rust-lang.org/1.5.0/book/compiler-plugins.html
rustc can load compiler plugins, which are user-provided libraries that extend the compiler's behavior with new syntax extensions, lint checks, etc.
- clang - https://clang.llvm.org/docs/ClangPlugins.html
Clang Plugins make it possible to run extra user defined actions during a compilation.
- ocmal - https://ocaml.org/releases/4.07/htmlman/plugins.html
it is possible to extend the native and bytecode compilers with plugins using the -plugin command line option of both tools
- kotlin - https://kotlinlang.org/docs/reference/compiler-plugins.html
- maven - https://maven.apache.org/plugins/maven-compiler-plugin/
- php - https://www.php.net/manual/en/extensions.php
- gradle - https://plugins.gradle.org/
there is more, but this short list should be enough
Orta Therox (@orta) do you have any updates about compile time plugins? this feature was requested few years ago
No updates
This would be very handy for Vue, Angular, Svelte. Right now all of these have implemented a TypeScript language service and a TypeScript plugin, all going different routes and patching different internal things because there's no blessed/official way to support this. The proposal seems good as it would provide a very low level and flexible API which would enable tricking TS into thinking file X is TS and providing a mechanism for mapping code positions back and forth. This in combination with the existing options of decorating the TS features would work out great I think.
Additional use cases, analogous to the the use case already given for graphql in that the current solution is to use code generators, which is both annoying and prone to human error - aka I updated the spec, but forgot to re-run the codegen, so everything looks to be running correctly...
- Automatically providing the types from an OpenAPI spec file.
- Automatically providing the types from an AsyncAPI spec file.
And ditto for anything else that defines interfaces in non-TS files that could be converted to TS type specifications.
Bonus points if the plugins are able to find and override imports. That would allow the plugin to be added to files in a way that doesn't corrupt the global namespace. Something like the "node:" prefix that node uses:
import * as MyNamespace from "tsplugin:mytypeplugin";
import { MyType } from "tsplugin:mytypeplugin";
function myFunc(p as MyType): MyNamespace.MyOtherType {
//
}Another use cases which would use such pre-compiler plugin:
- Declaratice Custom Elements to read HTML and convert to typescript with custom elements definitions.
- HTML embedded script code to treat embedded typescript
I am working on the DCE and have to replicate whole chain of IDE and type checking support by converting into TS plus other IDE-specific metadata. Hooking pre-compilation plugin into custom extension and conversion into TS during TSC and in language service would serve the purpose best.
Orta Therox (@orta) do you have any informations about this proposal?
Search Terms
Extension, Plugin, Vue, Custom extensions
I found some issues but no proposal :/
Suggestion
Hi! I'm an author of the
fork-ts-checker-webpack-plugin. Last few months I was busy with rewriting this plugin to pay off the technological debt.One of the features that this plugin provides is support for the Vue.js Single File Components. I was able to implement it but in order to work with the
Watchprogram andSolutionBuilderI had to do some workarounds. It's because there is an assertion in the TypeScript source code that files cannot have a custom extension.The main issue with this approach is that you have to implement these workarounds in every TypeScript's API client and they can behave differently (like
appendTsSuffixToin thets-loader). I know that there are already Language Service Plugins, but they don't work if you use different API, likeWatch.The proposal
A new type of TypeScript plugins that can pre-compile custom source code to the format that TypeScript understands. The simplified interface would be:
This architecture would allow adding new plugin types in the future (so we could add
ModuleResolutionPluginto support Yarn PnP in the future)The maintenance cost of this feature should be low because the exposed API is pretty simple.
There is a point in the TypeScript Design Goals
If you think that this feature is incompatible with this point, we could limit it to emitting only
.d.tsfiles.I could try to implement it, but first I need to know if it's something that you would like to add to the TypeScript and if this API is a good direction :)
Use Cases
I imagine that community would create
PreCompilerPlugins for a lot of use cases. For example:vue-typescript-plugin- support for the Single File Componentsmdx-typescript-plugin- support for embedded TypeScript in the MDX filesgraphql-typescript-pluging- support for generation of GraphQL types / clients in the runtime (so we don't have to use generators anymore)css-modules-typescript-plugin- support for typed css modules (instead ofdeclare module '*.css';)Examples
tsconfig.json
{ "compilerOptions": { "target": "ES6", "module": "CommonJS", "lib": ["ES6"], "moduleResolution": "Node", "resolveJsonModule": true, "esModuleInterop": true, "baseUrl": "./src", "outDir": "./lib", "plugins": [{ "name": "vue-typescript-plugin" }] }, "include": ["./src"], "exclude": ["node_modules"] }node_modules/vue-typescript-plugin/index.ts
It's a pseudo-code based on the
fork-ts-checker-webpack-pluginimplementation. It adds support for the.vuefiles.Checklist
My suggestion meets these guidelines: