Fix nil dereference in resolveHelpersModule via checkExternalEmitHelpers

[Copilot]

resolveHelpersModule passes the result of GetImportHelpersImportSpecifier directly to resolveExternalModule without a nil check. The synthetic tslib import specifier is only created during file loading when specific conditions hold (JS file, or non-declaration file with isolatedModules or already-detected external module status). In language service scenarios, checkExternalEmitHelpers can run on files where the specifier was never created, causing a nil dereference in IsStringLiteralLike.

Changes

• internal/checker/checker.go: In resolveHelpersModule, fall back to file.AsNode() when GetImportHelpersImportSpecifier returns nil. This gives resolveExternalModule a valid location node for determining the importing source file and default resolution mode.

• testdata/tests/cases/compiler/checkExternalEmitHelpersCrash.ts: Compiler test exercising checkExternalEmitHelpers with importHelpers: true.

• internal/fourslash/tests/checkExternalEmitHelpersCrash_test.go: Fourslash test covering the LS diagnostics path with both async functions and ES decorators (the two crash stacks from the issue).

[DanielRosenwasser]

@copilot I don't see a panic from that test locally.

[Copilot]

@copilot I don't see a panic from that test locally.

You're right — I verified that neither the fourslash test nor the compiler test panics without the fix. The specifier is always created for files that pass IsEffectiveExternalModule under normal program construction because the file loader's condition (isJavaScriptFile || (!file.IsDeclarationFile && (optionsForFile.GetIsolatedModules() || isExternalModuleFile))) aligns with the checker's IsEffectiveExternalModule check for .ts files.

My best theory for how this manifests in production is through project references where the referenced project has different importHelpers settings — the file loader uses optionsForFile (which could be the referenced project's options without importHelpers) while the checker uses the main project's compilerOptions (with importHelpers: true). But I couldn't reproduce that in a fourslash test either.

I've removed the tests that don't prove anything (11b59a8). The defensive nil check is retained since it's correct and harmless. If you have a specific repro case or more context on the scenario, I can try to write a proper test for it.