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
Implement ES2022 static initialization blocks? #1093
Comments
Sync from #1136 Version (complete output of 5.10.0 Complete CLI command or default Expected result That's already stage 4, supported by nodejs, browser and acorn (v8.5.0) |
Why Terser does not just "try" to optimize the code and if there is a syntax it can't understand, it does the bare minimum and throws a warning? |
Terser (and other build time JavaScript tools) operate on "Abstract Syntax Trees" (ASTs) rather than textual source code. This first involves "parsing" to build up a model of the input source before performing transformations and serialising the result. When new syntax is introduced that doesn't fit the existing parsing rules it will throw rather than blindly proceeding into undefined behaviour territory. For a very narrow selection of syntactic features (e.g. from one unexpected bracket to the next corresponding closing bracket) you could imagine a mode where a parser just plays dumb and repeats the tokens blindly, but this is very likely to produce invalid output. If your only reference to a variable appeared in that block, Terser might decide it's unused and remove it. It's hard to imagine an outcome where it doesn't cause more problems than it solves. At a minimum Terser's parser needs to be taught how to parse these new blocks, how to represent their new scopes (if any) internally and how to correctly serialise them. That's without looking for fancy optimisations to inline them. (Terser has its own parser, rather than using Acorn, so this is not just a matter of bumping a dependency) |
Thank you for taking the time to answer. |
Based on past interactions with the project, the underlying goal is to support stage 4 syntax. Highlighting Issues with that goal in mind is a good idea. It looks like in the past Fábio added the This could also be applied to (inexhaustive): |
Hey there! I read this but didn't interact. I'm prioritizing some of the bugs right now but this is a slow project. I want to start implementing things that are at stage 3 but I'm not sure I should, as technically they can still change right? |
You're doing your best and we love you
Stage 3 is a call for implementation so in a perfect world you should implement a new feature at stage 3 and then:
|
I just wanted to stop by and say this feature would be very helpful as I'm experiencing syntax errors while using Apollo Client and Apollo Elements. I'm searching for work arounds as I don't believe this will be done in time to help my project. `281308 | window.addEventListener('apollo-controller-disconnected', this.onElementDisconnected);
|
I've implemented basic support for this. As far as I can tell, it's pretty solid (though slightly conservative on the code removal side). Will probably release this monday, if not the next one. |
Hello! This relatively new feature from the next standard landed on V8 and SpiderMonkey recently, and I wanted to give it a try, but Terser doesn't seem to recognize it, and I wonder if it could be implemented? Thanks!
Bug report or Feature request?
Feature request.
Version (complete output of
terser -V
or specific git commit)terser 5.9.0
Complete CLI command or
minify()
options usedNot sure, as I'm using it via WebPack.
terser
inputterser
output or errorUnexpected token: punc ({)
Expected result
No errors.
The text was updated successfully, but these errors were encountered: