TypeScript file extensions are allowed in the `exports`/`imports` fields without `allowImportingTsExtensions`

[emmatown]

Bug Report

🔎 Search Terms

exports imports field extensions

🕗 Version & Regression Information

This has been the behaviour since TypeScript has had module resolution modes that have supported the exports/imports fields.

💻 Code

// @module: nodenext

// package.json
{
  "imports": {
    "#*": "./*"
  }
}
// a.ts
export function a() {}

// b.ts
// this is allowed, I don't think it should be without `allowImportingTsExtensions`
// since if you replaced the `#` with `./`, it would error and `#` and `./` should mean the same thing here
import { a } from '#a.ts'

a()

🙁 Actual behavior

TypeScript extensions can be used in the exports/imports fields without allowImportingTsExtensions: true. The example above has no errors regardless of allowImportingTsExtensions: true or not. I used patterns in the example since it quite clearly illustrates how it seems like the wrong behaviour since if you replaced the # in the import with ./, it would error which doesn't really make a lot of sense since the imports field here literally means "replace # with ./ but relative to this package.json".

🙂 Expected behavior

TypeScript extensions should only be allowed in the exports/imports fields when allowImportingTsExtensions is enabled.

I'm not at all expecting this to actually be changed since just like #50762, it would totally break the ecosystem since people have packages like this:

// package.json
{
  "name": "pkg",
  "exports": {
    "types": "./types.d.ts",
    "default": "./somewhere-else.js"
  }
}
// types.d.ts
export declare function a(): void;
// somewhere-else.js
function a() {}
exports.a = a;

but I think this might be a helpful discussion like #50762 since I think the fact that this works is a large part of what makes people have the wrong mental model for how TS finds declaration files, especially when you start talking about dual mode packages.

Imagine if the above wasn't allowed without allowImportingTsExtensions and instead you had to write this package.json:

{
  "name": "pkg",
  "exports": {
    "types": "./types.js",
    "default": "./somewhere-else.js"
  }
}

It seems very weird to write since there isn't a file at ./types.js but that's really the point. It's not something you should do and using .js makes that clear. And for the case where you have a sibling .d.ts file, having a types condition would look so clearly unnecessary:

{
  "name": "pkg",
  "exports": {
    "types": "./somewhere.js",
    "default": "./somewhere.js"
  }
}

And for the dual package case where you do it wrong, it's much easier to see why something's wrong than if you were using .d.ts:

{
  "name": "pkg",
  "exports": {
    "types": "./somewhere.js",
    "import": "./somewhere.mjs"
    "require": "./somewhere.js"
  }
}

[fatcerberus]

And for the dual package case where you do it wrong, it's much easier to see why something's wrong than if you were using .d.ts:

I’m glad you said this because I personally stared at your first package.json example for like 5 minutes going “Wait, what’s wrong with this, it’s just telling TS where to find the types which would obviously be in a .d.ts file”… and then I read the above quote and it finally clicked “OHHH, right, it’s never correct to specify a single type definition for both import and require but this encourages doing just that just from the structure alone.”

My momentary confusion pretty much proved your point. 😄

[RyanCavanaugh]

This is the intended behavior.

allowImportingTsExtensions: true is about whether or not you can import files by name including their extensions.

The things you write in import blocks in package.json are specifiers, not file names. If you wrote

{
  "imports": {
    "i.like.ts": "somefile.js"
  }
}

it'd be incorrect to say you can't import i.like.ts.

* in this context should be thought as a macro expansion.

cc Andrew Branch (@andrewbranch) to confirm

[andrewbranch]

Well... I don’t know. When you have a module specifier like "foo.ts" that goes through a path mapping in compilerOptions.paths, the compiler does make a distinction about whether the .ts was part of the pattern or part of the wildcard match. In other words, "foo.ts" is always allowed when it matches against

"foo.ts": ["./dist/foo.js"]

or even

"*.ts": ["./dist/*.js"]

but it’s not allowed when it matches against

"*": ["./dist/*"]

because it recognizes that you’re essentially asking the runtime to match a .ts extension on the file system, just like any relative module specifier, even though another part of the path has been rewritten.

I thought this was the case for "imports" and "exports" too, so I think this might be a bug.

Imagine if the above wasn't allowed without allowImportingTsExtensions and instead you had to write this package.json:

{
  "name": "pkg",
  "exports": {
    "types": "./types.js",
    "default": "./somewhere-else.js"
  }
}

I see what you mean, but it’s a leap to imply that allowImportingTsExtensions should apply to the filenames written in package.json files. TS has always processed "main": "index.ts" without complaint, and compilerOptions.paths is allowed to map to TS files. I honestly don’t think we have a coherent theory of what it means if we see something like that.

My first impression is it would probably make sense to make "imports" and "exports" work the same as compilerOptions.paths and error when a .ts suffix is written in the module specifier and matches against a filename via a wildcard substitution. I doubt that would be super breaky.

[RyanCavanaugh]

I guess I would philosophically object to

  "imports": {
    "foo.ts": "cool-foo.ts"
  }

working differently from

  "imports": {
    "*.ts": "cool-*.ts"
  }

"Expansion of wildcard works differently from wildcard" is a bug report in its own right if we were to do that

[andrewbranch]

Those aren’t supposed to work differently, because in both cases, the .ts is verbatim in the pattern. What makes the difference is when the only mention of .ts comes from the source file text. Consider

"name": "mod",
"exports": {
  "./*": ["./dist/*"],
  "./wow.ts": ["./bin/wow.js"]
}

There is quite clearly a difference between an import of "mod/helpers.ts" and "mod/wow.ts". The former is definitely going to make a request to a .ts file (./dist/helpers.ts) specifically because you wrote .ts at the end of your import, whereas the latter is (a) explicitly blessed by the package config, and (b) resolves to a .js file anyway.

It might be reasonable to say that any module specifier that resolves through any kind of remapping—at least package.json-based remapping—with or without wildcards, shouldn’t be subject to any “is this module specifier going to be runtime safe” checks because the expectation is that the package is going to direct TS resolution to some types and runtime resolution to something else. And if TS resolution gets specifically directed to some types, it abandons the path of figuring out what the runtime is going to resolve to. And that’s the current behavior. So yeah, maybe it is working as intended 😄

[typescript-bot]

This issue has been marked 'Working as Intended' and has seen no recent activity. It has been automatically closed for house-keeping purposes.