microsoft / microsoft/TypeScript

`./*.d.ts` required in `exports` to avoid `Cannot be named without a reference to... not portable...`

Open
#60,913 12 comments 3 reactions 1 assignee View on GitHub

@weswigham is already working on this.

Since Oct 9, 2025.

Needs Investigation
Dominant language
Go
Stars
111k
Forks
14.3k
Avg merge
2d 4h
Merged PRs (30d)
132

Description

🔎 Search Terms

The inferred type of '...' cannot be named without a reference to... This is likely not portable. A type annotation is necessary.

🕗 Version & Regression Information

Between 5.3 to 5.7 (latest)

⏯ Playground Link

No response

💻 Code
TSconfig of importing project
{
  "compilerOptions": {
    "outDir": "./lib",
    "rootDir": "./src",
    "tsBuildInfoFile": "./lib/.tsbuildinfo",

    "target": "ESNext",
    "module":"ESNext",
    "moduleResolution":"bundler",

    "composite": true,
    "declarationMap": true,
    "sourceMap": true,
    "strict": true,
    "esModuleInterop": true,
    "forceConsistentCasingInFileNames": true,
    "noErrorTruncation": true,
    "verbatimModuleSyntax": true,

    "emitDeclarationOnly": true,
    "skipLibCheck": true,

    "allowJs": true,

    
  },
  "include": ["src/**/*"]
}
Package.json of project BEING IMPORTED
{

  "type": "module",
  "files": [
    "lib/**/*",
    "src/**/*"
  ],
  "exports": {
    "./lib/*.d.ts": "./lib/*.d.ts",
    ".": {
      "types":"./lib/index.d.ts",
      "import":"./lib/index.js"
    }
  },
}

🙁 Actual behavior

If you do not include "./lib/*.d.ts": "./lib/*.d.ts" in the package.json of the imported project, you will receive the ...likely not portable... error.

However, in none of the documentations and searches I've seen was this written as a requirement. As a result, I assume it's a bug.

The problem with the above solution is that it exposes the .d.ts files, which causes intellisense import suggestions to suggest two imports (one from the proper path, and one from the .d.ts path).

Note:

  1. The import is a direct dependency, not a transitive dependency.
  2. Using main:./lib/index.js instead of exports:... also removes the error.
🙂 Expected behavior

Should not need to explicitly export all types

Additional information about the issue

No response

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.