`rewriteRelativeImportExtensions` errors on relative import

[JakobJingleheimer]

🔎 Search Terms

rewriteRelativeImportExtensions, monorepo, relative import, file extension

🕗 Version & Regression Information

5.8.3

⏯ Playground Link

No response

💻 Code

{
  "compilerOptions": {
    "allowImportingTsExtensions": true,
    "allowJs": true,
    "allowSyntheticDefaultImports": true,
    "checkJs": true,
    "esModuleInterop": true,
    "incremental": true,
    "isolatedModules": true,
    "lib": [ "dom" ],
    "module": "esnext",
    "moduleResolution": "bundler",
    "noImplicitAny": true,
    "resolveJsonModule": true,
    "skipLibCheck": true,
    "strictNullChecks": true,
    "verbatimModuleSyntax": true,
    "baseUrl": "./src",
    "rewriteRelativeImportExtensions": true,
    "outDir": "./build",
    "target": "es2022",
    "resolvePackageJsonExports": true,
    "resolvePackageJsonImports": true,
    "preserveConstEnums": true,
    "useDefineForClassFields": true
  },
  "files": […],
  "include": [
    "src/**/*.ts"
  ],
  "exclude": [
    "node_modules"
  ]
}

🙁 Actual behavior

TSC errors (and the error is kind of broken):

error TS2877: This import uses a '.ts' extension to resolve to an input TypeScript file, but will not be rewritten during emit because it is not a relative path.

Found 1 error.

🙂 Expected behavior

It should work

Additional information about the issue

This occurs in a monorepo like so:

pkgs/
  A
    src/…
    package.json
    tsconfig.json
  B
    src/…
    package.json
    tsconfig.json
  Shared
    src/…
    package.json
    tsconfig.json (config only for VS Code)
tsconfig.json
package.json

A & B get built and published. Shared does not (it is only ever consumed directly by A or B).

// pkgs/A/src/main.ts

import sql from '../../shared/src/helpers/sql.ts';

running tsc in pkgs/A fails, erroneously claiming ../../shared/src/helpers/sql.ts is not a relative path.

[RyanCavanaugh]

We need something we can clone; "monorepo" does not refer to a single configuration but rather a class of tools and ways of setting things up, the specifics of which are important here.

[JakobJingleheimer]

It's not runnable, but this should give you a more concrete idea: https://github.com/JakobJingleheimer/ts-monorepo-with-shared

If shared is installed via npm or the like, dev mode will work, but when app or server get built, shared will not get transpiled (and specifiers rewritten) per rewriteRelativeImportExtensions's design (not arguing it should). So that option is kinda out the window.

[RyanCavanaugh]

Please open a new issue when you can provide a runnable repo; we don't have resources to guess at what you're doing.

[JakobJingleheimer]

You must have misunderstood or I was not clear. The provided repo works perfectly fine for the purposes of this issue. It is not runnable in terms of an app or server you can use.

[JakobJingleheimer]

Also, some context: this is a continuation of a conversation I had with Jake, who suggested this behaviour may be a bug and requested I open this issue.

I am asking this question because I will be expanding node's guide on using and publishing TypeScript projects (for consumption by node). This helps you as it heads off questions your users would otherwise ask you. Dismissing this issue is not in your interest.

[RyanCavanaugh]

@JakobJingleheimer I absolutely understand, and what I need is a runnable repo. I can't validate bugs that don't have repro steps