fix(napi/parser): reorder fields of `ExportEntry` on JS side #16403

overlookmotel · 2025-12-02T17:34:09Z

NAPI-RS 3.6.0 makes a change to the ordering of objects. It now puts optional fields last.

This made tests in napi/parser for module record fail when we tried to update (#16383) because the module_request field of ExportEntry moves to last which breaks the snapshots.

The change in NAPI-RS is unlikely to be reverted, because it's a sizeable perf optimization: napi-rs/napi-rs#2990

To work around this problem:

Move the field in the ExportEntry intermediate struct in napi/parser to last, so NAPI's output matches what you'd expect from the struct definition.
Alter the #[estree] attr on ExportEntry struct in oxc_syntax crate to match.

Note: The ExportEntry struct in napi/parser is just an intermediate structure used for serialization. So I think it's fine to fiddle with its field order. The actual ExportEntry struct used in the module record is in oxc_syntax crate, and it remains unaltered.

overlookmotel · 2025-12-02T17:34:25Z

fix(napi/parser): reorder fields of ExportEntry on JS side #16403 👈 (View in Graphite)
main

How to use the Graphite Merge Queue

Add either label to this PR to merge it via the merge queue:

0-merge - adds this PR to the back of the merge queue
hotfix - for urgent hot fixes, skip the queue and merge this PR next

You must have a Graphite account in order to use the merge queue. Sign up using this link.

_{An organization admin has enabled the Graphite Merge Queue in this repository.} _{Please do not merge from GitHub as this will restart CI on PRs being processed by the merge queue.}

This stack of pull requests is managed by Graphite. Learn more about stacking.

codspeed-hq · 2025-12-02T17:39:59Z

CodSpeed Performance Report

Merging #16403 will not alter performance

_{Comparing 12-02-fix_napi_parser_move_exportentry_module_request_field_to_last (18d85c2) with main (f29e7a5)¹}

Summary

✅ 42 untouched
⏩ 3 skipped²

No successful run was found on main (b0fd9b1) during the generation of this report, so f29e7a5 was used instead as the comparison base. There might be some changes unrelated to this pull request in this report. ↩
3 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

overlookmotel · 2025-12-02T17:42:38Z

Merge activity

Dec 2, 5:42 PM UTC: The merge label '0-merge' was detected. This PR will be added to the Graphite merge queue once it meets the requirements.
Dec 2, 5:42 PM UTC: overlookmotel added this pull request to the Graphite merge queue.
Dec 2, 5:48 PM UTC: Merged by the Graphite merge queue.

…16403) NAPI-RS 3.6.0 makes a change to the ordering of objects. It now puts optional fields last. This made tests in `napi/parser` for module record fail when we tried to update (#16383) because the `module_request` field of `ExportEntry` moves to last which breaks the snapshots. The change in NAPI-RS is unlikely to be reverted, because it's a sizeable perf optimization: napi-rs/napi-rs#2990 To work around this problem: 1. Move the field in the `ExportEntry` intermediate struct in `napi/parser` to last, so NAPI's output matches what you'd expect from the struct definition. 2. Alter the `#[estree]` attr on `ExportEntry` struct in `oxc_syntax` crate to match. Note: The `ExportEntry` struct in `napi/parser` is just an intermediate structure used for serialization. So I think it's fine to fiddle with its field order. The actual `ExportEntry` struct used in the module record is in `oxc_syntax` crate, and it remains unaltered.

Copilot

Pull request overview

This PR adapts the ExportEntry serialization to accommodate NAPI-RS 3.6.0's performance optimization which places optional fields last in serialized objects. The change ensures test snapshots pass by aligning the field order across Rust, TypeScript, and generated code.

Moved module_request optional field to last position in StaticExportEntry struct definition
Updated #[estree] attribute with explicit field_order to control serialization
Regenerated all affected code including TypeScript definitions, ESTree serializers, and JavaScript deserializers

Reviewed changes

Copilot reviewed 3 out of 13 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
napi/parser/src/types.rs	Moved `module_request` field from line 185 to line 203 in `StaticExportEntry` struct
napi/parser/src-js/index.d.ts	Updated TypeScript definition to match Rust struct field ordering
crates/oxc_syntax/src/module_record.rs	Added `field_order` attribute to `#[estree]` macro to explicitly control serialization order
crates/oxc_syntax/src/generated/derive_estree.rs	Regenerated ESTree serializer with `moduleRequest` field serialized last
napi/parser/generated/deserialize/*.js	Updated all 8 deserializer variants to construct objects with `moduleRequest` property last
napi/parser/test/snapshots/esm.test.ts.snap	Updated snapshot expectations to reflect new field ordering in JSON output

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

…ll` (#16411) Follow-on after #16383 and #16403. While working on those I discovered an option NAPI-RS has to represent `Option::None` as `null`, instead of omitting the field entirely. Use that option on the structs used for transferring errors and module record over to JS. I think this is likely more performant because: 1. NAPI-RS can create all properties of the objects using only the faster `node_api_create_object_with_properties` API. 2. It produces consistent object shapes, so JS engine can better optimize code using these objects. It also brings the shape of the data perfectly into line between standard transfer and raw transfer, and is consistent with how empty fields in the AST are represented as `null`. I would have used this option before if I'd known it existed. ### Breaking change I've marked this as a breaking change because code consuming these objects would now need to check for empty fields with `value === null` instead of `value === undefined`. However in practice, most people probably use `!value` or `value ?? ...`, so it's unlikely to affect many users. This only affects module record and errors anyway, not the AST itself, as we transfer that as JSON, not via NAPI.

…16412) Revert the change made in #16403. It's no longer necessary after #16411, because NAPI-RS no longer re-orders the fields.

…ll` (oxc-project#16411) Follow-on after oxc-project#16383 and oxc-project#16403. While working on those I discovered an option NAPI-RS has to represent `Option::None` as `null`, instead of omitting the field entirely. Use that option on the structs used for transferring errors and module record over to JS. I think this is likely more performant because: 1. NAPI-RS can create all properties of the objects using only the faster `node_api_create_object_with_properties` API. 2. It produces consistent object shapes, so JS engine can better optimize code using these objects. It also brings the shape of the data perfectly into line between standard transfer and raw transfer, and is consistent with how empty fields in the AST are represented as `null`. I would have used this option before if I'd known it existed. ### Breaking change I've marked this as a breaking change because code consuming these objects would now need to check for empty fields with `value === null` instead of `value === undefined`. However in practice, most people probably use `!value` or `value ?? ...`, so it's unlikely to affect many users. This only affects module record and errors anyway, not the AST itself, as we transfer that as JSON, not via NAPI.

…xc-project#16412) Revert the change made in oxc-project#16403. It's no longer necessary after oxc-project#16411, because NAPI-RS no longer re-orders the fields.

### 💥 BREAKING CHANGES - 083fea9 napi/parser: [**BREAKING**] Represent empty optional fields on JS side as `null` (#16411) (overlookmotel) ### 🚀 Features - 7a2afee parser: Add TS1174 error for classes extending multiple base classes (#15993) (sapphi-red) - da87812 semantic: Add TS2309 error for export assignment with other exports (#15992) (sapphi-red) - d6d2bcd minifier: Remove unused function calls that are marked by `manual_pure_functions` (#16534) (sapphi-red) - c90f053 minifier: Support `.` separated values for `compress.treeshake.manualPureFunctions` (#16529) (sapphi-red) - a607cc4 codegen: Preserve comments between CatchClause's param and body (#16167) (copilot-swe-agent) - 8c10694 semantic: Expose get_comment_at method (#16439) (camc314) - 3981e7a ast: Add get_comment_at to lookup a comment by span (#16438) (camc314) ### 🐛 Bug Fixes - 699406a napi/parser: Move `ExportEntry::module_request` field to first (#16412) (overlookmotel) - 12bd794 napi/parser: Move `ExportEntry::module_request` field to last (#16403) (overlookmotel) ### ⚡ Performance - 790beeb napi/parser: Do not remove extraneous options on JS side (#16447) (overlookmotel) Co-authored-by: Boshen <[email protected]>

…xc-project#16403) NAPI-RS 3.6.0 makes a change to the ordering of objects. It now puts optional fields last. This made tests in `napi/parser` for module record fail when we tried to update (oxc-project#16383) because the `module_request` field of `ExportEntry` moves to last which breaks the snapshots. The change in NAPI-RS is unlikely to be reverted, because it's a sizeable perf optimization: napi-rs/napi-rs#2990 To work around this problem: 1. Move the field in the `ExportEntry` intermediate struct in `napi/parser` to last, so NAPI's output matches what you'd expect from the struct definition. 2. Alter the `#[estree]` attr on `ExportEntry` struct in `oxc_syntax` crate to match. Note: The `ExportEntry` struct in `napi/parser` is just an intermediate structure used for serialization. So I think it's fine to fiddle with its field order. The actual `ExportEntry` struct used in the module record is in `oxc_syntax` crate, and it remains unaltered.

…ll` (oxc-project#16411) Follow-on after oxc-project#16383 and oxc-project#16403. While working on those I discovered an option NAPI-RS has to represent `Option::None` as `null`, instead of omitting the field entirely. Use that option on the structs used for transferring errors and module record over to JS. I think this is likely more performant because: 1. NAPI-RS can create all properties of the objects using only the faster `node_api_create_object_with_properties` API. 2. It produces consistent object shapes, so JS engine can better optimize code using these objects. It also brings the shape of the data perfectly into line between standard transfer and raw transfer, and is consistent with how empty fields in the AST are represented as `null`. I would have used this option before if I'd known it existed. ### Breaking change I've marked this as a breaking change because code consuming these objects would now need to check for empty fields with `value === null` instead of `value === undefined`. However in practice, most people probably use `!value` or `value ?? ...`, so it's unlikely to affect many users. This only affects module record and errors anyway, not the AST itself, as we transfer that as JSON, not via NAPI.

…xc-project#16412) Revert the change made in oxc-project#16403. It's no longer necessary after oxc-project#16411, because NAPI-RS no longer re-orders the fields.

### 💥 BREAKING CHANGES - 083fea9 napi/parser: [**BREAKING**] Represent empty optional fields on JS side as `null` (oxc-project#16411) (overlookmotel) ### 🚀 Features - 7a2afee parser: Add TS1174 error for classes extending multiple base classes (oxc-project#15993) (sapphi-red) - da87812 semantic: Add TS2309 error for export assignment with other exports (oxc-project#15992) (sapphi-red) - d6d2bcd minifier: Remove unused function calls that are marked by `manual_pure_functions` (oxc-project#16534) (sapphi-red) - c90f053 minifier: Support `.` separated values for `compress.treeshake.manualPureFunctions` (oxc-project#16529) (sapphi-red) - a607cc4 codegen: Preserve comments between CatchClause's param and body (oxc-project#16167) (copilot-swe-agent) - 8c10694 semantic: Expose get_comment_at method (oxc-project#16439) (camc314) - 3981e7a ast: Add get_comment_at to lookup a comment by span (oxc-project#16438) (camc314) ### 🐛 Bug Fixes - 699406a napi/parser: Move `ExportEntry::module_request` field to first (oxc-project#16412) (overlookmotel) - 12bd794 napi/parser: Move `ExportEntry::module_request` field to last (oxc-project#16403) (overlookmotel) ### ⚡ Performance - 790beeb napi/parser: Do not remove extraneous options on JS side (oxc-project#16447) (overlookmotel) Co-authored-by: Boshen <[email protected]>

github-actions bot added the A-parser Area - Parser label Dec 2, 2025

github-actions bot added the C-bug Category - Bug label Dec 2, 2025

overlookmotel marked this pull request as ready for review December 2, 2025 17:42

Copilot AI review requested due to automatic review settings December 2, 2025 17:42

overlookmotel self-assigned this Dec 2, 2025

overlookmotel added the 0-merge Merge with Graphite Merge Queue label Dec 2, 2025

Copilot started reviewing on behalf of overlookmotel December 2, 2025 17:42 View session

graphite-app bot force-pushed the 12-02-fix_napi_parser_move_exportentry_module_request_field_to_last branch from 18d85c2 to 12bd794 Compare December 2, 2025 17:42

overlookmotel changed the title ~~fix(napi/parser): move ExportEntry::module_request field to last~~ fix(napi/parser): reorder fields of ExportEntry on JS side Dec 2, 2025

Copilot finished reviewing on behalf of overlookmotel December 2, 2025 17:44

Copilot AI reviewed Dec 2, 2025

View reviewed changes

graphite-app bot merged commit 12bd794 into main Dec 2, 2025
21 checks passed

graphite-app bot deleted the 12-02-fix_napi_parser_move_exportentry_module_request_field_to_last branch December 2, 2025 17:48

graphite-app bot removed the 0-merge Merge with Graphite Merge Queue label Dec 2, 2025

This was referenced Dec 2, 2025

chore(deps): update napi #16383

Merged

feat(napi/parser)!: represent empty optional fields on JS side as null #16411

Merged

fix(napi/parser): move ExportEntry::module_request field to first #16412

Merged

graphite-app bot pushed a commit that referenced this pull request Dec 2, 2025

fix(napi/parser): move ExportEntry::module_request field to first (#…

699406a

…16412) Revert the change made in #16403. It's no longer necessary after #16411, because NAPI-RS no longer re-orders the fields.

Boshen mentioned this pull request Dec 8, 2025

release(crates): oxc v0.102.0 #16595

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Uh oh!

fix(napi/parser): reorder fields of `ExportEntry` on JS side #16403

fix(napi/parser): reorder fields of `ExportEntry` on JS side #16403

Uh oh!

overlookmotel commented Dec 2, 2025 •

edited

Loading

Uh oh!

overlookmotel commented Dec 2, 2025

Uh oh!

codspeed-hq bot commented Dec 2, 2025

Uh oh!

overlookmotel commented Dec 2, 2025 •

edited by graphite-app bot

Loading

Uh oh!

Copilot AI left a comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

fix(napi/parser): reorder fields of ExportEntry on JS side #16403

fix(napi/parser): reorder fields of ExportEntry on JS side #16403

Uh oh!

Conversation

overlookmotel commented Dec 2, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

overlookmotel commented Dec 2, 2025

How to use the Graphite Merge Queue

Uh oh!

codspeed-hq bot commented Dec 2, 2025

CodSpeed Performance Report

Merging #16403 will not alter performance

Summary

Footnotes

Uh oh!

overlookmotel commented Dec 2, 2025 • edited by graphite-app bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Merge activity

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

fix(napi/parser): reorder fields of `ExportEntry` on JS side #16403

fix(napi/parser): reorder fields of `ExportEntry` on JS side #16403

overlookmotel commented Dec 2, 2025 •

edited

Loading

overlookmotel commented Dec 2, 2025 •

edited by graphite-app bot

Loading