Support `.js` → `.ts` conversion in local export map

[remcohaszing]

Feature request

Using tsx it’s possible to write import … from './index.js'. It’s ok if index.js doesn’t exist, but only index.ts. It will just resolve to that.

If package.json contains an exports field, it’s valid to import the package by name instead of by a path reference.

For example, after compilation of https://github.com/remcohaszing/remark-mdx-frontmatter, it’s valid to rewrite the compiled test to use import remarkMdxFrontmatter from 'remark-mdx-frontmatter' in test.ts. This won’t work without compiling first.

I suggest to make tsx use the same logic for aliasing .js → .ts after resolving package.json exports as it does for relative imports.

Why?

1. When testing the public interface, tests closer match how a user would use a package.
2. This allows to use tsx for importing other local packages inside a mono repo.

Alternatives

N/A

Additional context

No response

[privatenumber]

Does TypeScript follow this resolution logic?

[remcohaszing]

Does TypeScript follow this resolution logic?

Yes. (I think as of version 4.7)

[privatenumber]

Confirmed this is TypeScript behavior:

index.ts

import test from 'test-package';
console.log(test);

node_modules/test-package/package.json

{ "exports": "./file.js" }

node_modules/test-package/file.ts

export default 1234;

Output

$ npx tsc --noEmit --traceResolution

...

======== Resolving module 'test-package' from '/test-js-ext-ts/index.ts'. ========
Explicitly specified module resolution kind: 'Node16'.
File '/test-js-ext-ts/package.json' exists according to earlier cached lookups.
Loading module 'test-package' from 'node_modules' folder, target file type 'TypeScript'.
Found 'package.json' at '/test-js-ext-ts/node_modules/test-package/package.json'.
'package.json' does not have a 'typesVersions' field.
File name '/test-js-ext-ts/node_modules/test-package/file.js' has a '.js' extension - stripping it.
File '/test-js-ext-ts/node_modules/test-package/file.ts' exist - use it as a name resolution result.
Resolving real path for '/test-js-ext-ts/node_modules/test-package/file.ts', result '/test-js-ext-ts/node_modules/test-package/file.ts'.
======== Module name 'test-package' was successfully resolved to '/test-js-ext-ts/node_modules/test-package/file.ts'. ========

...

[monsanto]

To save anyone else blocked by this issue some time: I tried out a number of TypeScript loaders and unfortunately ts-node is the only one I know of that handles this aspect of TypeScript's module resolution algorithm correctly.

[Snurppa]

Stumbled here when suspecting that tsx watch did not recompile when a file imported via "Subpath imports" was edited.

Edit: After few changes in my local environment, tsx seems to work just fine even when using subpath imports.
Something was off, one of them being that I had old builds in dist/, which were picked up in "dev mode" with tsx.

Sorry for the original inaccurate comment. I will leave my original comment (with fixed package.json) comment below.

Summary is that with TS 5.4-beta the combination of tsx watch + "imports": {"#app/*":...} + import logger from '#app/utils/logger.js' + no "paths": in tsconfig.json is working fine in watch mode.

FYI I am using tsx watch --conditions=development to pick "correct" subpath import in development mode (./src/*) vs in "production" mode when running with plain Node (./dist/*).

Original comment about `tsx watch` with subpath imports in TS 5.4-beta

Stumbled here when noticing that tsx watch did not recompile when file imported via "Subpath imports" was edited.

This is sort of FYI, but thought to inform that I was excited to use a TS feature, currently in TS 5.4-beta (microsoft/TypeScript#55015), with which I was able to accomplish "single source of truth" by just defining package.json "imports", without using duplicate TS Config "paths" declaration.

My "imports"/"exports" in package.json:

{
  "name": "my-backend",
  "version": "1.0.0",
  "type": "module",
  "engines": {
    "node": ">= 18.17.0"
  },
  "exports": {
    ".": "./dist/index.js",
    "./sensor.json": "./sensor.json"
  },
  "imports": {
    "#app/*": {
      "development": "./src/*",
      "default": "./dist/*"
    }
  }

tsconfig.json from `tsc --showConfig`, long list of `"files": [..]` omitted

{
    "compilerOptions": {
        "lib": [
            "es2023"
        ],
        "module": "node16",
        "target": "es2022",
        "strict": true,
        "esModuleInterop": true,
        "skipLibCheck": true,
        "forceConsistentCasingInFileNames": true,
        "moduleResolution": "nodenext",
        "composite": true,
        "incremental": true,
        "declaration": true,
        "declarationMap": true,
        "outDir": "./dist",
        "rootDir": "./src",
        "moduleDetection": "force",
        "allowSyntheticDefaultImports": true,
        "resolvePackageJsonExports": true,
        "resolvePackageJsonImports": true,
        "useDefineForClassFields": true,
        "noImplicitAny": true,
        "noImplicitThis": true,
        "strictNullChecks": true,
        "strictFunctionTypes": true,
        "strictBindCallApply": true,
        "strictPropertyInitialization": true,
        "alwaysStrict": true,
        "useUnknownInCatchVariables": true
    },
    "include": [
        "src/**/*.ts"
    ],
    "exclude": [
        "node_modules"
    ]
}

I have files:

• src/api/proxy/wms.ts
• src/utils/logger.ts

With wms.ts having import logger from '#app/utils/logger.js', tsx watch doesn't notice changes in logger.js.

TypeScript 5.4-beta successfully resolves the module, here is an excerpt from tsc --traceResolution regarding successful resolution of subpath import:

======== Resolving module '#app/utils/logger.js' from 'src/api/proxy/wms.ts'. ========
Explicitly specified module resolution kind: 'NodeNext'.
Resolving in ESM mode with conditions 'import', 'types', 'node'.
'paths' option is specified, looking for a pattern to match module name '#app/utils/logger.js'.
File 'src/api/proxy/package.json' does not exist according to earlier cached lookups.
File 'src/api/package.json' does not exist according to earlier cached lookups.
File 'src/package.json' does not exist according to earlier cached lookups.
File 'package.json' exists according to earlier cached lookups.
Using 'imports' subpath '#app/*' with target './dist/utils/logger.js'.
File 'src/utils/logger.ts' exists - use it as a name resolution result.
Resolving real path for 'src/utils/logger.ts', result 'src/utils/logger.ts'.
======== Module name '#app/utils/logger.js' was successfully resolved to 'src/utils/logger.ts' with Package ID 'my-backend/src/utils/logger.ts@1.0.0'. ========

I think the 'paths' option is specified... logging is confusing here, as the PR was recently merged and only released in beta, so I assume it is just a relic string in TS. Because I don't have any "paths": ... declared in tsconfig.json.

Dunno if this was of any help in the future, but anyway I want to thank you for the great tool and efforts here!

[privatenumber]

Duplicate of #341 and fixed via 4503421