TypeScript 4.1.3 resolves aliases through nested CommonJS exports

A JavaScript value can pass through a module wrapper before a consumer destructures it. TypeScript needs to follow that path through both property lookup and export aliases to preserve the value's type. TypeScript 4.1.3, published December 11, includes a repair for a missing alias-resolution step in this particular CommonJS import pattern.

The patch since 4.1.2 describes the affected form as a CommonJS require followed by property access. A destructured member could fail to resolve correctly when it represented an export alias. The runtime JavaScript operation remained valid. The compiler needed to recover the declaration that the alias referred to.

I value TypeScript's ecosystem partly because it can help with JavaScript that already exists, including library packaging conventions an application did not choose. Correctly following a re-export is useful maintenance work even when it adds no new syntax to a TypeScript source file.

The value passes through a nested wrapper

The regression test shipped with 4.1.3 uses three JavaScript files. One file exports an object member using a shorthand property. Another exports the first module under a nested property. The consumer requires the wrapper, selects that property, then destructures the original member.

The following example keeps that structure while giving the value a domain-specific name. Each comment identifies a separate file, so the declarations do not belong in one shared JavaScript scope.

// first.js
const setting = { label: "queue" };
module.exports = { setting };

// second.js
module.exports = { nested: require("./first") };

// main.js
const { setting } = require("./second").nested;
console.log(setting.label);

The wrapper does not change the object's shape. It changes the route by which the consumer reaches the export. A checker has to connect the shorthand export in the first module with the member obtained after the nested access in the third.

This is a useful minimal reproduction because it preserves the indirection that matters. Removing the wrapper or using an unrelated direct import would exercise a different path. A successful check of that simpler program would not establish that the nested re-export case works.

Property lookup and alias resolution are separate steps

The checker change wraps the result of getPropertyOfType in a call to resolveSymbol. The affected branch already identified the CommonJS property-access case. It could find a property, but returning that property symbol without resolving its alias missed the final connection.

The patch passes the existing dontResolveAlias parameter through the added call. That preserves the surrounding operation's choice about alias resolution. The correction therefore belongs within the existing symbol-resolution policy rather than replacing all property lookups with unconditional alias following.

This explains why the defect is more specific than a general failure to understand CommonJS. The compiler already knew enough to find the required module and nested property. The missing step arose when the selected exported member itself needed resolution through an alias.

The implementation change is one line, but the test spans several files because those files establish the relationship the line must preserve. Counting edited lines would understate the behaviour being checked. The important evidence is the value's recovered type at the consumer.

The baseline records the resulting type

The expected type baseline records the original test member as an object with a string-valued property. It also records the nested property as the imported first module. Those intermediate results show that the consumer receives type information through the wrapper.

The test enables JavaScript checking and disables emission. It therefore exercises the analysis of existing JavaScript module code without depending on emitted TypeScript output. The desired result is a correct account of the imported value in the checking and language-service machinery.

The baseline does not claim that the mutable object's string property becomes a string-literal type. Its recorded shape uses string. That distinction matters when explaining what the repair preserves. Alias resolution recovers the declared or inferred type; it does not independently strengthen that type into a narrower contract.

I prefer that concrete baseline to describing the release as simply improving inference. The consumer's value has an identifiable shape, and the nested module has an identifiable source. That makes the repaired relationship useful to someone debugging a library wrapper.

Existing module shapes remain supported inputs

This patch does not ask library authors to replace their CommonJS wrappers with another module system. It repairs the compiler's understanding of a valid existing shape. The application can retain its nested property access while the checker follows the exported alias to its target.

For the example's consumer, the useful result is ordinary property information after destructuring. The member retains its object type through the wrapper, so subsequent checking can reason about its string property. The missing alias-resolution call now sits on the CommonJS property-access path that supplies that information.