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

Move post emit bundling out to Rust #5607

Closed
kitsonk opened this issue May 18, 2020 · 1 comment
Closed

Move post emit bundling out to Rust #5607

kitsonk opened this issue May 18, 2020 · 1 comment
Labels
cli related to cli/ dir

Comments

@kitsonk
Copy link
Contributor

kitsonk commented May 18, 2020

This issue is for tracking purposes of something the core team is working on. Informed feedback is welcomed, but please think before commenting.

Moving the post emit bundling out to Rust requires a few things we are doing in compiler.ts that might be hard inside of Rust:

  • Because of Expose emitted module specifiers on AMD outfile emit microsoft/TypeScript#35052 there is no way to determine from the AST what the module names will be when emitted. This requires for us to "guess" at what they will be as the logic is buried deep in the compiler and not easy to get to. There is some code in compiler.ts that mimics this logic. We need this to identify what the emitted root module name is so we can instantiate the bundle. It has to determine the common root of all the module specifiers in the bundle and then transform the root module specifier into what the emitted specifier will be in the bundle. That is replacing the common root with an empty string and removing the extension from the module specifier. (Yes, the TypeScript compiler always remove that extension even if it has it everywhere else. 🤷)
  • We have to "wrap" the emitted bundle with bundle loader. Because we need to preprend it, it messes up the source map that would get emitted. If we manipulate it and remap it in Rust we could close Consume source maps from JavaScript files #4499. I don't know if we want an inline source map or not. My feeling is not as long as we could resolve it at runtime when consuming a bundle, but we don't currently do that. Inline simply bloats the bundle, especially if we were to include sources.
  • We has to do a static analysis of the root module to figure out what exports are there, so we can re-export them in the bundle. This is currently done in the compiler.ts, and we would have to use swc to do that analysis in there. A temporary measure would be to still do the analysis in there, but have the bundle response include the string names of the exports to Rust, and Rust does the bundle manipulation. This is probably better as we already have the AST sitting there after the bundle emit.

This all would be an interim step until we start doing transformation only in Rust.

@kitsonk
Copy link
Contributor Author

kitsonk commented Oct 24, 2020

This is redundant, since bundling has been moved to swc.

@kitsonk kitsonk closed this as completed Oct 24, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cli related to cli/ dir
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants