Name change?

[juliankrispel]

Have you considered a name change? Search engines think that this project name is a typo, which isn't great for visibility, which in turn is a shame because this project is amazing 🙏

[cevek]

yeah, it was bad idea to add just one letter to name :).
so, what name do you proposal?

[Griffork]

Why not something simple like Typescript Transformer?

Other options:

• Typescript Transform Factory/Handler/Wrapper.
• tsconfig Transforms (although people searching for ttypescript or typescript transforms won't hit this).

[juliankrispel]

@cevek that should be up to you imo. Maybe a poll?

Personally I like what @Griffork mentioned - "Typescript Transformer" - or "ts-transform" for short? Would match keywords quite well and also it would make for a great logo/graphic (which I'd love to design btw 😀)

[cevek]

and also we need new name to commandline tsc

[Griffork]

ttsc (or tsct or tsc-tr) is fine for command line, as long as it's documented somewhere.

[cspotcode]

If #96 is implemented, then this project can be named pluggable-typescript or typescript-plugins. CLI name can be ptsc or tscp.

This project could accomplish TypeStrong/discussions#5

[nonara]

Instead of just a name change, what do you think about a mutual rewrite, effectively replacing this and ts-patch? I've been thinking about this for awhile now.

Here's my proposal and a discussion #113

[Griffork]

@cspotcode I suspect most people looking for this repo will be using typescript's official name for compiler plugins which is transforms, so I'd still recommend using that as the name.
That doesn't prevent ttypescript from doing what you suggest and putting an entry in the readme about it (which should show up when searching for typescript plugins).

---

Ninja'd by @nonara: I already have a local hack (replacing a few files) to add my own configuration file so I could support a configuration heirarchy (allowing me to ship the compiler with default transforms enabled) and a few other nice things. I'm planning on making more changes like hopefully figuring out how to add tsserver support. The creator of this repo is busy on other projects atm so this repo isn't a high priority for them. You may be able to get pull requests submitted but I don't think cevek is going to be adding any more code themselves.

[cspotcode]

Can typescript transformers change diagnostics? I thought that was not possible since noEmit exists. I was thinking that if we add features which transformers cannot do, then it might make sense to broaden the name, and ttypescript uses the word "plugins" internally. The language service has "plugins" which can change diagnostics; it's a bummer they don't work for the tsc CLI.

…

On Fri, Feb 5, 2021, 6:22 PM Griffork ***@***.***> wrote: @cspotcode <https://github.com/cspotcode> I suspect most people looking for this repo will be using typescript's official name for compiler plugins which is transforms, so I'd still recommend using that as the name. That doesn't prevent ttypescript from doing what you suggest and putting an entry in the readme about it. ------------------------------ Ninja'd: I already have a local hack (replacing a few files) to add my own configuration file so I could support a configuration heirarchy (allowing me to ship the compiler with default transforms enabled) and a few other nice things. I'm planning on making more changes like hopefully figuring out how to add tsserver support. The creator of this repo is busy on other projects atm so this repo isn't a high priority for them. You may be able to get pull requests submitted but I don't think cevek is going to be adding any more code themselves. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#105 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAC35OGZCY7C2PFY5TSMMRDS5R4U3ANCNFSM4TNSNBNA> .

[Griffork]

@cspotcode what do you mean about diagnostics? Do you mean custom syntax output or error reporting or something else?

[nonara]

@cspotcode Yeah, that's why I thought 'extensions' made more sense. Especially if we allow for additional patching and combining LS plugins with transformers into one package.

Can typescript transformers change diagnostics?

In order to get that to work, I had to add some additional hooking. There's API for it that gets fed to your entry point in ts-patch. That's one area that the two projects diverge

[cspotcode]

Typescript internally refers to all typechecking errors as "diagnostics." It's my understanding that they are generated by the typechecker, and transformers cannot modify/add/remove them in noEmit mode. Language service plugins, however, can modify diagnostics.

…

On Fri, Feb 5, 2021, 6:29 PM Griffork ***@***.***> wrote: @cspotcode <https://github.com/cspotcode> what do you mean about diagnostics? Do you mean custom syntax output or error reporting or something else? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#105 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAC35OFHPFA2JKTIAEXWTX3S5R5MXANCNFSM4TNSNBNA> .

[nonara]

@cspotcode If noEmit is set, I believe transformers don't get run, so that's a good point. In that case, tsp would not allow modification. That's another reason I'd like to a see a redesigned system that wasn't centered around transformers alone.

[Griffork]

@cspotcode oooh. I've just been hacking transformers to act a bit like language service plugins (which has quite restricted what I've been able to do with them). Outputting to console.error with the correct format seems to get picked up by IDEs and is indistinguishable to a normal tsc error afaik so I just made a helper to do that.

When looking at Typescript's code I didn't really see any support for language service plugins the same way that there's support for transformers. So unless transformers can also be language service plugins I might be missing something.