Plugin Support for Custom Transformers #14419
Comments
|
We do not plan on exposing compiler plugin system in the short term. The transforms are exposed as part of the public API as you noted, and we are in the process of writing documentation and samples for these. |
|
I don't want to have an exposed plugin API. Instead, I would prefere way to register my custom transforms by just specifying them in the tsconfig.json instead of having to use the TS-Compiler API. Because using the TS-Compiler API implies that I can no longer use the tsc command line tool which further can imply that it does no longer integrate nicely into existing build tools and workflows. |
|
anything update about documentation and samples ? @mhegazy |
|
@MichaReiser you can write a simple compiler based on the API (sample here). We actually use TS very heavily within Yahoo Finance and the transformer public API have been awesome. Those are some of the transformers we wrote after it became public: @mhegazy lmk if you need help documenting/gathering samples |
|
@longlho That is what I'm currently doing. However, it makes it impossible to use other build tools created for typescript, e.g. web pack loaders, jest loaders. Besides, how can I use one of your plugins together with one of mine when each of us uses a different frontend? Therefore, I do believe that the current approach is a good start but not sufficient for a plugin ecosystem. Because using a plugin is too much effort for the user and requires more than just writing the transformation code for the author. I believe a plugin system like the one of Babel is essential for typescript if the goal is to encourage the community to create and use custom transformers. |
|
@MichaReiser yup. I'm not saying it's sufficient for the ecosystem, just good enough for the 1st step towards it. |
|
I'd like to add support for transforms in gulp-typescript, but I want to prevent that all TypeScript plugins (for gulp, webpack etc) propose a different API. And TypeScript might add even a different way for configurating this later on. So do you currently have plans to add this in the near or far future? |
|
Hi all, I try to write a preprocessor, but nothing comes out :[ In fact, I have two questions:
// 1. Input
class Foo {
templateString = 'some value';
}
// 2. After transformation
import __LIB__ from '@external/lib';
class Foo {
templateString = (function compiledTemplate(deps) {
// ...
return result;
})({lib: __LIB__});
}
// 3. Expected result
var lib_1 = require("@external/lib");
var Foo = (function () {
function Foo() {
this.templateString = (function compiledTemplate(deps) {
// ...
return result;
})({ lib: lib_1 });
}
return Foo;
}());A Simplified Example: https://github.com/RubaXa/typescript-api-questions/tree/master/import-add |
|
@RubaXa Since you added the import declaration in a transform, it isn't bound or type checked. Since it wasn't bound or type checked, we cannot resolve One option is to use a namepace import instead of a default import, so that your emit is something like: import * as __LIB__ from "@external/lib"As there is no aliasing that can occur. The other hold onto a generated identifier for the import declaration, as per the attached zip |
|
@RubaXa if your goal is to pass in the entire module object, you probably want to use the |
|
yeah we're doing |
|
@rbuckton O, thanks a lot! function createFragmentFromString(code: string) {
// ????
}
function visitPropertyDeclaration(node) {
if (ts.isIdentifier(node.name) && node.name.text === "templateString") {
// ...
return ts.updateProperty(
node,
ts.visitNodes(node.decorators, visitor),
ts.visitNodes(node.modifiers, visitor),
ts.visitNode(node.name, visitor),
ts.visitNode(node.type, visitor),
createFragmentFromString('(function compiledTemplate() { /* ... */ })()')
);
}
return node;
} |
|
This is what i was hoping the transformer support and workflow would behave like in TypeScript. |
|
I am also very much interested in this feature. as @MichaReiser mentioned love to see inputs from experts/typescript compiler DEV . |
|
Looks like someone has wrapped typescript to expose this functionality. https://github.com/cevek/ttypescript Also looks like ts-loader has it: https://www.npmjs.com/package/ts-loader#getcustomtransformers-----before-transformerfactory--after-transformerfactory---- |
|
I think this is something that could land in typescript 2.8 release or at least in roadmap at some point, @ahejlsberg @mhegazy @DanielRosenwasser what do you think? In this way custom transformers might be more popular and therefore more powerfull. Having option to plugin in transfromer from tsconfig.json perspective would simplify life a lot. |
|
We have no plans to expose plugins in the short term, as noted earlier. |
|
@mhegazy Is it a considered decision or is it out of scope just because of low community interest? |
|
We need this, please!! 🥺 |
|
+1 |
|
+1 Badly needed for my intended project. |
|
We need this |
|
Given the huge list of projects already using this, you would think it's time to put it on the roadmap. 🤔 And this list is just projects using it specifically for reflection - another neglected feature many people miss bad enough that they'll go and build their own solutions; even with no official support for building such a feature, meaning every single one of these projects "hack" this feature in somehow. I understand the list of requested features remains huge, but these are clearly two of the most sought-after features. You would think someone on the team would take note. If they were to officially open up the language to third-party extensions, I'm sure a lot of these features would get built by the rather large community already trying to "hack" them in without a sanctioned, stable API. |
|
No one has mentioned yet that Angular is forking the entire typescript compiler to add AOT compilation of templates. Curiously, Angular folks have put the rewrite of the Angular compiler as a TS plugin on their roadmap. |
|
Would be awesome if we had this in our project. |
|
I am looking to do some comple-time massaging of the exported types from my library so I can massively simplify its development. When investigating options I found that the You already have support for it in the compiler API, you already have the Would the TS team be open to PRs for this? There is enough support for this feature that we can definitely make the actual implementation happen as long as the TS team will receive it. |
|
Please seriously consider this! There really is no harm in supporting this as far as I can see, and implementation would be very simple. All it really requires is calling each plugin during transformation! |
|
When this issue was opened I was 16 years old and just started using TypeScript, this problem went way over my head and didn't understand what it was about. I'm now 23 and been following this thread for a little bit more than 6 years. The question is: Will my kids be able to write transformers in an easy manner without depending on external wrappers like |
|
bump We need this feature |
|
We need this feature :) |
|
we need this feature, thanks! |
|
The lack of an official transformer means that users will have to create and use their own. But every time a version of Typescript goes up, the libraries suffer and need to be updated. Among them is The point is that the lack of an official transformer is an inconvenience for many users and slows down the evolution of the language's ecosystem. |
|
Hello @sunrabbit123 Your documentation shows an incomplete type declaration for the plugins: (program: ts.Program, config?: PluginConfig) => ts.TransformerFactory;In fact there is a third argument which is important. (program: ts.Program, config: PluginConfig, helpers: { ts: typeof ts; addDiagnostic: (diag: ts.Diagnostic) => void }) => ts.TransformerFactory;Passing references to I think it's important that authors of their own compilers and plugins maintain this standard. |
|
@sosoba We'll move it to an issue for decontextualization. |
|
TS 5 update is shutting down all transformers based libraries for one month. It's a recurring problem whenever TS version be updated. Currently, @nonara (author of It's been a while since this issue was opened, and we know that these requests are repeated all the time. What are the barriers to supporting official p.s) Currently, the author of STC has promised to provide plugin API. It's just a pity that the official TypeScript compiler doesn't have the plug-in capabilities that the unofficial TypeScript compiler provides. |
|
Assume the answer were "yes", let's add custom transformers, ignoring all previously-presented reasons not to do it (this is a long thread I have not read in totality). Note that this issue is not "compiler plugins" (#16607) which is a massively less approachable idea compared to the very well-defined idea of "just allow extra transformers". These are the challenges I see so far:
I don't think this is in any way blocked by documentation. If you believe there are holes in our current documentation, those would totally benefit from a dedicated issue. See also #53239. |
|
@samchon There are valid reasons for why the team chose not to do this, many of which Jake detailed above. Regarding keeping up with TS changes, part of the reason it took longer for me to do this time is because it was time to fundamentally change the underlying structure to make what we're doing easier. It was long overdue. So, not only will keeping up be easier in the future, we will ultimately be adding CI to monitor dev builds. This will help us add support for new versions before they're released. As a side note, I would like to kindly ask that people not post issues on the TS repo that pertain to ts-patch. I recognize that your comment here is more broad and applies to this discussion, so I'm more referring to some of the other posts that have been made recently. Namely, I've been tagged a few times in complaints directed toward the TS team about changes that broke tsp. I'd like to remind everyone that the onus is on us to keep up, and Jake has been kind enough to even let us know ahead of time when big changes happen. TLDR is - Right now, you can use beta3, which is stable. In the future, we are working to better avoid gaps between supporting new versions. |
|
I have just filed #54276, which is a concrete / minimal proposal for closing this issue. In short, the proposal currently being evaluated simply adds the ability to provide I expect that we'll probably close this long thread at some point; it's gotten so unwieldy and large that I'm not sure that it's very useful anymore. If we do #54276, it will not preclude any new features or additional extensibility of |
and others
Since #13764 has landed, it's easy to write custom transformers. However, if I understand the API correctly, it is needed to duplicate the whole tsc command line just to add a single transformer. This leads to incompatibilities since these, on typescript depending, applications do not support the same features as the tsc command line tool.
It, therefore, would be favored to have a plugin system that allows loading Custom Transformers from third party node modules as this is the case for the language service proxies #12231. These transformers then easily integrate into existing build tools / build workflows.
If someone experienced has inputs on how to implement the changes, I'm willing to create a PR as it would simplify my project tremendously.
The text was updated successfully, but these errors were encountered: