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

Implement ES2022 static initialization blocks? #1093

Closed
torralbaalla opened this issue Oct 23, 2021 · 9 comments
Closed

Implement ES2022 static initialization blocks? #1093

torralbaalla opened this issue Oct 23, 2021 · 9 comments

Comments

@torralbaalla
Copy link

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 used
Not sure, as I'm using it via WebPack.

terser input

class A
{
    static
    {
        let b = "c";
    }
}

terser output or error
Unexpected token: punc ({)

Expected result
No errors.

@LongTengDao
Copy link
Contributor

Sync from #1136

Version (complete output of terser -V or specific git commit)

5.10.0

Complete CLI command or minify() options used

default

Expected result

That's already stage 4, supported by nodejs, browser and acorn (v8.5.0)

@madmoizo
Copy link

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?
Or an opt-out option like strict: boolean
I didn't expect to be stopped by Terser because of the syntax I use

@tchetwin
Copy link
Contributor

tchetwin commented Jun 4, 2022

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)

@madmoizo
Copy link

madmoizo commented Jun 5, 2022

Thank you for taking the time to answer.
If an option, even opt-in, is too unpredictable, the only way is to plan the support for new syntaxes when they reach stage 4.
Create a pinned issue and ask for contributions or w/e

@tchetwin
Copy link
Contributor

tchetwin commented Jun 6, 2022

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 modern syntax label: here. help wanted could also help.

This could also be applied to (inexhaustive):

@fabiosantoscode
Copy link
Collaborator

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?

@madmoizo
Copy link

madmoizo commented Jun 6, 2022

I'm prioritizing some of the bugs right now but this is a slow project.

You're doing your best and we love you

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?

Stage 3 is a call for implementation so in a perfect world you should implement a new feature at stage 3 and then:

  • merge when the stage 4 is reached
  • merge directly as an experimental feature behind an opt-in flag

@peterschuelke
Copy link

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);
281309 | }

281310 | static { this.is = 'apollo-client'; }
| ^ Unexpected token: punc ({)
281311 | static { this.observedAttributes = [
281312 | 'uri',
281313 | 'validate-variables',
[!] (plugin terser) SyntaxError: Unexpected token: punc ({)`

@fabiosantoscode
Copy link
Collaborator

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants