replace ts-node with sucrase-node

[jeremy-coleman]

hi, this cli is exactly what i need, ( rather, its not everything i don't need). thank you.

Quick proposal, is to use sucrase-node as the bin for transpiling the config. I've been using it for about a month as a replacement for ts-node and let me say its beautiful. ts-node is annoying af because if you're in a web project with an es target in your tsconfig, ts-node is going to error and it makes me rage. sucrase node doesn't do that , auto supports jsx, typescript and flow. its the biz

Requested Behavior / Situation

Use sucrase-node instead of ts-node

Actual Behavior / Situation

ts-node makes me want to smash my kb

Modification Proposal

use sucrase-node

[shellscape]

Glad you find this useful!

While I couldn't justify forcing all TypeScript users to use a non-official binding, we might be able to create an option to allow you to specify which binding you'd like to use. Would that satisfy your situation?

[jeremy-coleman]

yes definitely - i saw the options in rechoir , i just really have no idea how to make cli's.

(this is unrelated to wp) I was putting together a starter demo for wp + webpack serve plugin with electron yesterday. It works great mostly, except 1 thing - when I use webpack-node-externals I get an error saying cannot read error of undefined

[jeremy-coleman]

i put it up here if you want to mess with it at all or include as an example somewhere - its using both webpack plugin serve and webpack nano

https://github.com/jeremy-coleman/multi-product-starter

[G-Rath]

@jeremy-coleman would you be able to provide a bit more detail on what actually happens with ts-node when you try and use webpack-nano?

I've personally been using webpack, ts-node, and typescript across a number of projects for a few years now (not necessarily all at once, or on the same projects) without any errors relating to es build targets that I can remember.

In saying that, the whole reason I ask is that I'm looking into setting up webpack for a node-lambda project, and trying a .ts webpack config for the first time.

When I attempt to run wp --config webpack.config.ts I get this error:

RangeError: Unable to use specified module loaders for ".ts":
    ts-node/register,
    typescript-node/register,
    typescript-register,
    typescript-require

Which might be b/c of other problems with my configuration, but since I am targeting es2018, I wondered if it could be what you're having too.

One possible solution for this problem could be to just somehow provide a custom tsconfig.json for ts-node to use. This already should be doable externally if you have your webpack configs in their own folder, but since it's common practice to have webpack configs at the root of a project, that might be something to look into.

The erroring aside, is there any other benefit to using sucrase-node over ts-node, such as performance? I never even knew about it until reading this post, but would be interested in a comparison if one is available 😄

[shellscape]

(And apologies that I haven't been able to give this attention over the last few weeks. Life on my end is quite hectic but should be settling down soon)

[G-Rath]

Having played around with this some more, I think I can confirm that the issue is that ts-node uses the tsconfig.json of the directory you're in, meaning if you have all your configs in a config dir with a tsconfig.json with a module property of commonjs, things seem to work fine.

My initial error was caused by not having ts-node installed :joy:

So I think a nice solution to this would be to add some method of passing a custom tsconfig.json to ts-node. I know the whole point of webpack-nano is to not have a lot of flags, but I think this is the only way to support both ts-node & not require the user to have their configs in a separate directory, which screws with __dirname & path.resolve :/

[shellscape]

The rechoir project is what this module is using, and probably the best place to ask for that. It would be whack-a-mole for this project to support config flags for every module loader available.

[G-Rath]

It would be whack-a-mole for this project to support config flags for every module loader available.

Agreed, I was more thinking supporting one "moduleLoaderFlags" flag, that let you pass a string to whatever module loader was being used. Similar to how npm test -- <flags> results in <flags> being passed to whatever scripts.test is. (Maybe -- would even be the best to use...?)

I'm a bit confused on what I should be asking of rechoir? If they need to add a moduleLoaderFlags property, then you'd still need to add one too right?

I just want to make sure I've got my facts straight & know what I'm asking who before I charge off :)

[shellscape]

They might be willing to support an envar, or examine process.argv within rechoir. Or they might have a completely different solution. If they ball/pass on implementing something, then we can explore getting something into webpack-nano.

[G-Rath]

So I think this might already be supported by interpret?

My understanding of how rechoir is working is that it takes an interpret configuration, and uses that to figure out how to handle whatever files its been chucked, meaning that rechoir is just a middleman & interpret is the one that should be able to handle extra configuration properties/arguments for its module loaders (which I think it does already).

Let me know if I have that wrong :)

[jeremy-coleman]

you can also just make your webpack.config.js

require('sucrase/register')
require('./myactualConfig.ts')

it doesn't need to be so complicated to transpile a webpack config, and imo having your tsconfig pointing to the wrong module config definately shouldn't break your build, i think its ridiculous ts-node doesn't (and refuses to) hardcode the config as node-compatible , makes absolutely no sense to me

[G-Rath]

I think it's ridiculous ts-node doesn't (and refuses to) hardcode the config as node-compatible

Except that import/export is node compatible. You can use esm or the --experimental-modules flag.

Hardcoding ts-node to override a tsconfig.json setting would do more harm than good in the long run, as it would make that version unusable with newer technologies that supported those es<year> targets.

What might make more sense could be some fork of, or mode/flag in, ts-node that does that overriding, but even then that'd only be useful if this was a common problem.

[jeremy-coleman]

K

[shellscape]

Going to close this one citing inactivity. It still looks like the best project to talk to about this would be rechoir (or its dependency interpret). Please feel free to continue the discussion, or if warranted, ping me and I'll reopen.

[G-Rath]

@shellscape have you seen my question in this comment?

It's been a while, but iirc when I looked at both rechoir & interpret it seemed like they had already got apis in place to allow configuration to support this feature :)