Skip to content

Conversation

@weswigham
Copy link
Member

@weswigham weswigham commented Oct 27, 2025

Fixes #1178

The bug was less that something was broken, and more like nobody ever added handling for the newly reparsed node kind to declaration emit at all. I'm not 100% sure how these should be translated to declarations, but I think I have reasonable transforms in the code. This is enough implementation to fix the crashes, but, looking at the baselines, behavior in some cases stands to be improved (since this is mostly just variants of the export assignment handling logic), as it produces some pretty ick output. In particular, multiple declarations not merging is... OK (different from strada, ofc), but maybe could use some checks to see if they can combine/be elided to improve the output. Additionally, some namespacey patterns that are seemingly not well supported checking-ways anymore have seemingly equally poor declaration emit (eg, var ns: typeof ns). Additionally, const-ness and maybe-const-initializer-y-ness of the variables isn't correctly handled yet (instead the non-const type is always emitted), which requires integrating some of the export var logic into the export assignment logic I reused. IMO, those are all reasonable follow-up improvements since I'm still trying to focus on normal emit, and really just wanted to fix the crash here.

Copy link
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull Request Overview

This PR fixes a crash in declaration emit caused by missing handling for the KindCommonJSExport node type, which was introduced during earlier CommonJS module parsing work but never implemented in the declaration transformer.

Key Changes

  • Added declaration emit support for KindCommonJSExport nodes
  • Handles both identifier-named exports (including default) and string-named exports with appropriate transformations
  • Added test case to prevent regression

Reviewed Changes

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

File Description
testdata/tests/cases/compiler/jsDeclarationExportDefaultAssignmentCrash.ts New test case for CommonJS default export crash
internal/transformers/declarations/util.go Added KindCommonJSExport to nodes with inferred types
internal/transformers/declarations/transform.go Implemented declaration emit transformation for CommonJS exports
Multiple baseline files Updated test baselines showing improved declaration emit output for CommonJS patterns

@@ -30,7 +30,7 @@
//// [a.d.ts]
-export const x: 0;
+export declare const x = 0;
+export var y = 0;
+export declare var y: number;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I saw this when trying to fix this crash too; definitely some weird widening interplay here

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, the old output was because the KindCommonJSExport declaration was just being emitted as-is. :S That's why we had things like export var x = { x: "x" } in the output which just...isn't actually something we should ever have in a declaration file? And is an error?

Comment on lines +22 to +24
+export declare var x: number;
+export declare var y: undefined;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Weird, we're taking the initial assignment for the type of these?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ensureType uses the serialized type of the declaration which, generally speaking, is inferred from the first initializer. It's just whatever getTypeOfSymbol returns, without any special handling for const-y-ness, excluding some special cases it already handles for TS code.

Copy link
Member

@jakebailey jakebailey left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Approving though because as you say, you know about the ick things, so I'd rather have the crash fixed and it be less ick unless you see an obvious way to fix the bigger icks.

Probably worth a new issue about it generally.

@jakebailey
Copy link
Member

Agh bitten by leftover baselines (main shouldn't do this anymore, usually)

@weswigham
Copy link
Member Author

Probably worth a new issue about it generally.

JS declaration emit, in general, needs a polish/completeness pass - nobody's just gone through the js declaration baselines and fixed all the diffs yet, since we've still been working on JS handing at the reparser step, afaik. What works is mostly by chance and commonality with TS (which is perhaps unsurprisingly a lot of it!).

@weswigham weswigham enabled auto-merge October 27, 2025 22:02
@weswigham weswigham added this pull request to the merge queue Oct 28, 2025
Merged via the queue into microsoft:main with commit 4037f3a Oct 28, 2025
22 checks passed
@weswigham weswigham deleted the new-js-decl-kind-crash branch October 28, 2025 17:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

"invalid memory address or nil pointer dereference"

2 participants