Name change? #105
Comments
|
yeah, it was bad idea to add just one letter to name :). |
|
Why not something simple like Typescript Transformer? Other options:
|
|
and also we need new name to commandline tsc |
|
ttsc (or tsct or tsc-tr) is fine for command line, as long as it's documented somewhere. |
|
If #96 is implemented, then this project can be named This project could accomplish TypeStrong/discussions#5 |
|
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 |
|
@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. 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. |
|
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>
.
|
|
@cspotcode what do you mean about diagnostics? Do you mean custom syntax output or error reporting or something else? |
|
@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.
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 |
|
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>
.
|
|
@cspotcode If |
|
@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. |
|
Ttypescript and ts-patch already hook into createProgram to override
methods, which adds support for transformers. It seems reasonable to
further hook the compiler to intercept and filter diagnostics, which should
hopefully avoid hacks. At least, avoid more hacks than what is already
necessary to hook the compiler. :D
…On Fri, Feb 5, 2021, 6:43 PM Griffork ***@***.***> wrote:
@cspotcode <https://github.com/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.
—
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/AAC35ODUC2I6DEVMAC6VVSTS5R7DZANCNFSM4TNSNBNA>
.
|
|
Also wanna drop this here, yarn 2's plugin-compat actually applies a patch
to typescript to support yarn2 pnp. They do it via a diff file which is
applied to the raw typescript package, and then the result is saved into
yarn's cache as a zip, same as all other packages. They have the luxury of
doing this within the package management/installation layer.
…On Fri, Feb 5, 2021, 6:49 PM Andrew Bradley ***@***.***> wrote:
Ttypescript and ts-patch already hook into createProgram to override
methods, which adds support for transformers. It seems reasonable to
further hook the compiler to intercept and filter diagnostics, which should
hopefully avoid hacks. At least, avoid more hacks than what is already
necessary to hook the compiler. :D
On Fri, Feb 5, 2021, 6:43 PM Griffork ***@***.***> wrote:
> @cspotcode <https://github.com/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.
>
> —
> 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/AAC35ODUC2I6DEVMAC6VVSTS5R7DZANCNFSM4TNSNBNA>
> .
>
|
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 🙏
The text was updated successfully, but these errors were encountered: