Skip to content

Add decorators in ESTree for JS files #10921

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

Open
ArnaudBarre opened this issue May 9, 2025 · 7 comments
Open

Add decorators in ESTree for JS files #10921

ArnaudBarre opened this issue May 9, 2025 · 7 comments
Assignees
Labels
blocker P-high Priority - High

Comments

@ArnaudBarre
Copy link
Contributor

Playground

There are visible in the Rust AST, is this something wanted to not exposed them? It's only stage 3 but given that they are already parsed, I think it's better to make them available than skip them

@ArnaudBarre ArnaudBarre changed the title Missing decorators in ESTree for JS files Add decorators in ESTree for JS files May 9, 2025
@Boshen Boshen self-assigned this May 11, 2025
@Boshen Boshen added P-high Priority - High blocker labels May 11, 2025
@Boshen
Copy link
Member

Boshen commented May 11, 2025

@overlookmotel
Copy link
Contributor

@ArnaudBarre Same question as #10978 (comment): What other parsers used in Prettier can parse decorators (apart from TS-ESLint)?

I'm struggling to work out how we can test this, because our testing infra is based around comparing to an existing implementation. TS-ESLint adds decorators fields everywhere, like on every Identifier etc. I suspect this is overkill for JS files, and would likely incur a perf hit, but I'm unclear which types should have decorators field, and which shouldn't.

@overlookmotel
Copy link
Contributor

overlookmotel commented May 15, 2025

Ah ha I have my answer as to which types should get decorators field: https://github.com/estree/estree/blob/master/stage3/decorators.md

But is there a reference implementation we can use for tests which follows this spec?

@fisker
Copy link

fisker commented May 16, 2025

What other parsers used in Prettier can parse decorators

flow and meriyah

Same answer #10978 (comment), mentioned in #10979, we can't ignore decorators, we need error to refuse formatting if not planned to support.

@overlookmotel
Copy link
Contributor

overlookmotel commented May 17, 2025

Thanks for coming back. Perhaps we can add meriyah to https://github.com/oxc-project/acorn-test262 to generate tests cases for decorators. If meriyah has exactly same output as Acorn, except for decorators and other Stage 3 features, this should not be too tricky. But does it? From aligning with TS-ESLint for TS types, we discovered there are subtle/obscure differences between parsers e.g. treatment of ranges/spans. We'll find out...

I guess another option is to try to conform to @babel/eslint-parser. That would be more future-proof, as new features always get implemented in Babel first.

Either way, I'll need to complete the work on field ordering first (#9705 (comment)), because different parsers definitely differ in that respect.

@Boshen
Copy link
Member

Boshen commented May 27, 2025

oxc-parser has landed in prettier, this is the last blocking issue before its stable release.

https://github.com/prettier/prettier/blob/40d9a7e2b0de094a5468883571a0f2767dd414ac/tests/config/run-format-test.js#L88-L100

@overlookmotel
Copy link
Contributor

Very much aware! I'm working on it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
blocker P-high Priority - High
Projects
None yet
Development

No branches or pull requests

4 participants