Skip to content

Instantly share code, notes, and snippets.

Show Gist options
  • Select an option

  • Save ssalbdivad/cef6f032e57e0ecbbcacf12530a79ef8 to your computer and use it in GitHub Desktop.

Select an option

Save ssalbdivad/cef6f032e57e0ecbbcacf12530a79ef8 to your computer and use it in GitHub Desktop.

Handling The inferred type of x cannot be named without a reference to y

This error is notoriously fickle to reproduce or resolve. It can always be fixed by adding an export type for a name TS needs to compile your types. Here's how to find where the change needs to be made:

  1. Navigate to the source of the diagnostic in the repo's _tsc.js file (line 52151 as of TS 5.7.3). You can search for reportLikelyUnsafeImportRequiredError to see all references to it if needed. Add a breakpoint in at that position:
if (!attributes) {
  // ADD BREAKPOINT HERE ⬇️
  context.encounteredError = true
  if (context.tracker.reportLikelyUnsafeImportRequiredError) {
    context.tracker.reportLikelyUnsafeImportRequiredError(oldSpecifier)
  }
}
  1. Open a Javascript Debug Terminal (Ctrl+Shift+P "JavaScript Debug" and you'll find it in VSCode).

  2. Run yarn attest stats to execute a type check in the package where the error exists. You could also run tsc directly, but the attest command adds flags to avoid using a cached result that would prevent the code from running.

  3. After a few seconds, your breakpoint should be hit (could be multiple times if you have multiple instances of the error in your package). When it is, navigate to the debug console (Ctrl+Shift+P "Show Debug" and you'll find it in VSCode).

  4. Evaluate chain.map(symbol => symbol.escapedName) in the debug console to see the problematic resolution chain and names involved. You can further introspect the associated symbols as needed to get more contextual information.

  5. Starting from the problematic symbol, work your way back to the original source file. For example, imagine the original error is in v1ApplicationId.ts:

import { ArtifactGenerationBuilder } from "@superwall/artifacts"


// TypeScript: The inferred type of 'v1ApplicationIdLive' cannot be named...
export const v1ApplicationIdLive = ArtifactGenerationBuilder.group(

And your debug console output looks like this:

['"/home/ssalb/paywall-next/packages/artifacts/dist/types/lib/ArtifactGroup"', 'GenerationGroup']

This tells us the problem is that files referencing GenerationGroup transitively are not able to resolve it. We can now fix the error by navigating to the file ArtifactGenerationBuilder is imported from and adding the following:

// existing import, still need this
import * as ArtifactGroup from "./ArtifactGroup"
// new: parallel export to ensure GenerationGroup can be resolved transitively
export type { GenerationGroup } from "./ArtifactGroup"

You may also choose to re-export all types from the problematic file if there's nothing specific about the way the problematic type is defined that seems to suggest a solution specific to it:

// existing import, still need this
import * as ArtifactGroup from "./ArtifactGroup"
// new (alternative): parallel export to ensure GenerationGroup can be resolved transitively
export type * as ArtifactGroup from "./ArtifactGroup"

Note you don't actually need to use this export anywhere for it to resolve the original issue if it is working correctly, though be sure to re-build your types if the reference crosses package boundaries and the types resolve to a .d.ts file. While working on a resolution, it may be helpful in such cases to modify the .d.ts files directly to identify the ideal re-exports.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment