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

Feature request: deep analysed annotations for cjs -> esm #2486

Closed
simon300000 opened this issue Aug 20, 2022 · 3 comments
Closed

Feature request: deep analysed annotations for cjs -> esm #2486

simon300000 opened this issue Aug 20, 2022 · 3 comments

Comments

@simon300000
Copy link

simon300000 commented Aug 20, 2022

Currently esbuild generate annotations for nodejs' cjs to esm lexer, which works well.

But if the input js file contains something like export * from 'package-x',
The exports of package-x is not in the annotation.

will it be possible for esbuild to read the exports of package-x and "re-emit" in the annotation of output file?

@hyrious
Copy link

hyrious commented Aug 20, 2022

FYI, nodejs uses cjs-module-lexer to lexically analyze source code to find exports. So we have several choices:

  1. Let esbuild annotate more names by analyzing other packages like you said. This would require esbuild to implement something like cjs-module-lexer. What's worse, it asks esbuild to read files that are not bundled (think of this scenario: a react-related library does not installed 'react' in its node_modules).
  2. Let cjs-module-lexer support parsing esbuild's code pattern of re-exports, they have already intentionally supported babel & typescript. So I just raised an issue there.

@evanw
Copy link
Owner

evanw commented Aug 22, 2022

It's probably possible to do this without modifying cjs-module-lexer (and also without reading the exports of the re-exported package). Modifying cjs-module-lexer to match esbuild's generated output based on identifiers would also not be robust because esbuild's generated identifiers can be renamed (to avoid collisions, or during minification). Instead, esbuild would have to emit something that matches what cjs-module-lexer is expecting. Maybe something like this (assuming that you are marking package-x as external):

0 && (module.exports = {
  ...require('package-x'),
  /* other exports */
});

This approach would also have the benefit of automatically working with older node versions which wouldn't ever get any fixes that might hypothetically be added to cjs-module-lexer.

@simon300000
Copy link
Author

This seems to me a far better approach, will you make this extra annotation in esbuild?

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

3 participants