-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Generate dummy exports for exported types #1398
Comments
Sorry, I'm confused. It's deliberate that esbuild does not generate exports for types, since esbuild is a tool to convert TypeScript to JavaScript and types do not exist in JavaScript. Transforming TypeScript into TypeScript is not something that esbuild does. If you need to do that, you'll likely need to do something like what you're currently doing (using the TypeScript compiler API). |
Sorry, I should have provided a more extensive example! I've created a sample repository that shows the issue and how I'm currently fixing it: https://github.com/fwouts/vite-type-import-example To reproduce: run
This is caused by the following in export { Button, ButtonProps } from "./Button"; To see the hack in action: uncomment the call to The problem I'm trying to solve is that an export statement that re-exports a type becomes a runtime error in the browser, because that export doesn't exist once converted to JS. This workaround makes the export valid, without impacting program semantics (since the export isn't actually used in the generated JS code). I believe this could be implemented in esbuild without impacting performance because we only need to parse top-level type export statements, there is no need to do any type resolution or any other complex computation. Does this help clarify what I'm aiming to do? |
You are trying to go against the way TypeScript works. TypeScript is designed to remove types when converting TypeScript to JavaScript. If you want to do something different, you will have to write your own custom code. This isn't something that should be a part of esbuild because it's not part of TypeScript either.
Both esbuild and Vite require |
Yup, I was expecting that answer. I'll keep using this hack instead, thanks for the response! 👍 |
Hi,
First off, thank you for creating esbuild. I'm using it through Vite and I'm astonished with the performance!
I'm aware that esbuild isn't designed to support type import statements such as
import { SomeType }
(instead one should useimport type { SomeType }
), especially when the type comes from a wildcard export. It's an understandable limitation to allow for files to be compiled independently.In my current project, which needs to run on projects that don't have
isolatedModules: true
in their tsconfig, I managed to work around this limitation by running the TypeScript parser on each file before esbuild runs, generating fake exports for each type with the following hack:findExportsWithNoValue
finds each type export where there isn't also a value export of the same name (see gist).For example, the following TypeScript file:
would become:
This means that type imports become effectively valid imports (even though they're unused).
Obviously, the hack I've implemented is far from efficient since it relies on running the full TypeScript parser on top of esbuild, for each file (although not within
node_modules
).I was wondering whether this approach had been considered in esbuild? I understand it's a bit of a hack, but I thought it might help some tools that rely on ESBuild (e.g. Vite and Snowpack), since we could probably remove the limitation of
isolatedModules: true
.I'd be happy to start a PR if there is interest in investigating this further.
The text was updated successfully, but these errors were encountered: