Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

esbuild-kit/tsx loader support for TypeScript configuration #3905

Open
fregante opened this issue Aug 1, 2023 · 9 comments
Open

esbuild-kit/tsx loader support for TypeScript configuration #3905

fregante opened this issue Aug 1, 2023 · 9 comments
Assignees

Comments

@fregante
Copy link

fregante commented Aug 1, 2023

Feature request

What is the expected behavior?

Webpack could use esbuild-kit/tsx automatically if found, just like it already supports:

  • ts-node/register
  • sucrase/register/ts
  • @babel/register
  • esbuild-register
  • @swc/register

What is motivation or use case for adding/changing the behavior?

I'd like to use this loader because it's the most straightforward I found so far, without issues and verbose configuration. I wish this was supported natively in Webpack.

How should this be implemented in your opinion?

Is it correct that Webpack uses interpret under the hood to load configuration? If so, I think this change can be followed up in its repo:

Are you willing to work on this yourself?

Potentially

Also we need:

  • tsimp support
@fregante
Copy link
Author

fregante commented Aug 1, 2023

Actually this should probably be moved to webpack-cli:

"interpret": "^3.1.1",

@snitin315
Copy link
Member

Yes, we use interpret in webpack-cli.

@alexander-akait alexander-akait transferred this issue from webpack/webpack Aug 7, 2023
@alexander-akait
Copy link
Member

@fregante I think we can provide an option to support loaders that is not supported by interpret, is it fine for you?

@fregante
Copy link
Author

fregante commented Aug 7, 2023

It seems to me that this already works but I was hoping to see native support since the package is quite popular (more than some existing parsers used by Interpret).

However this stopped working in Node 20. See:

@alexander-akait
Copy link
Member

@fregante I think we can send a PR for gulpjs/interpret#95 and ask to merge it, also, yeah, I can modify default loaders array and put this as a temporary workaround until interpret team merge

@evenstensberg evenstensberg self-assigned this Nov 18, 2023
@adarsh500
Copy link

Hey everyone, i'm pretty new here and i'd like to work on this issue

@webpack-bot
Copy link

This issue had no activity for at least half a year.

It's subject to automatic issue closing if there is no activity in the next 15 days.

@alexander-akait
Copy link
Member

bum

@silverwind
Copy link

silverwind commented Oct 8, 2024

If you can require Node.js users to set NODE_OPTIONS=--experimental-strip-types, it'd be the way to go imho, no bloated third-party loaders needed and this works out of the box in Bun and Deno too.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants