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

Integrate prepack.io into the compilation process #15761

Closed
michaelaird opened this issue May 11, 2017 · 4 comments
Closed

Integrate prepack.io into the compilation process #15761

michaelaird opened this issue May 11, 2017 · 4 comments
Labels
Discussion Issues which may not have code impact

Comments

@michaelaird
Copy link

It would be amazing if TypeScript could incorporate the functionality of
prepack.io into the compilation process to optimize runtime performance.

@kitsonk
Copy link
Contributor

kitsonk commented May 11, 2017

My feeling is that prepack is just another (slightly dangerous) post processor like uglify. Because of that, it would contradict the TypeScript design non-gloal:

  1. Provide an end-to-end build pipeline. Instead, make the system extensible so that external tools can use the compiler for more complex build workflows.

A tool like prepack could benefit from type information of code, of which the compiler services are available for that, though it would require significant changes to prepack to take advantage of those services.

Actually transforming the code from what was written, outside is required for down emits, would feel like it would contravene design goal #7:

  1. Preserve runtime behavior of all JavaScript code.

@michaelaird
Copy link
Author

I suppose it would also contravene:

  1. Aggressively optimize the runtime performance of programs. Instead, emit idiomatic JavaScript code that plays well with the performance characteristics of runtime platforms.

It seemed like a natural fit but maybe it's actually the other way around where people who want that optimization could hook prepack.io into some kind of "pre-emit" step that would leverage the TypeScript AST/type information.

@ahejlsberg ahejlsberg added the Discussion Issues which may not have code impact label May 11, 2017
@kitsonk
Copy link
Contributor

kitsonk commented May 11, 2017

The TypeScript language services are there and with the new emitter architecture. Someone could write an integrated sort of compiler. The challenge is that prepack uses Babel for its AST information. Whatever took advantage of the compiler services would either need to abstract prepack from the Babel AST or be a "TypeScript prepack" variant. Likely both outside of the scope of the main TypeScript compiler though.

@michaelaird
Copy link
Author

Ok. I'm going to go ahead and close this suggestion as outside the design goals of TypeScript, but it would be interesting if there was a workflow leverage this kind of optimization.

@microsoft microsoft locked and limited conversation to collaborators Jun 14, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Discussion Issues which may not have code impact
Projects
None yet
Development

No branches or pull requests

3 participants