-
Notifications
You must be signed in to change notification settings - Fork 12.8k
tsconfig "extends" field ignores "exports" field of source package #48665
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
|
Basically same as agilgur5/react-signature-canvas@cc6cce9 - this is my own tsconfig base (https://github.com/agilgur5/tsconfig) built on top of @tsconfig/strictest (https://github.com/tsconfig/bases) - as you can see, it just reduces all the non-type-checking related config that @tsconfig/strictest doesn't cover - TS doesn't yet support package `exports` for tsconfigs yet (microsoft/TypeScript#48665), hence the longer path into the package - Relative paths in tsconfig bases are also relative _within_ `node_modules` (microsoft/TypeScript#29172), so have to repeat any relative paths here - And due to this, I think it's better right now for `build` to extend the base here instead of the `build` tsconfig in `@agilgur5/tsconfig` - I didn't fully think that one through when I made it tbh, though it still serves as a good example tsconfig - Maybe that will be different in the future if TS changes or otherwise comes up with a solution to this (see the issue)
tsconfig.json's `extends` option uses legacy module resolution [1] and, as a result, does not honor package.json's `exports` field. This change publishes tsconfig.json at the root of the package so that it can be imported by consumers via `"extends": "bitumen"`. [1] microsoft/TypeScript#48665
tsconfig.json's `extends` option uses legacy module resolution [1] and, as a result, does not honor package.json's `exports` field. This change publishes tsconfig.json at the root of the package so that it can be imported by consumers via `"extends": "bitumen"`. [1] microsoft/TypeScript#48665
⚠️ BREAKING CHANGES (if using lint rules): - Transition from deprecated `@babel/plugin-syntax-import-assertions` to the new `@babel/plugin-syntax-import-attributes` and enable option `deprecatedAssertSyntax` for backward compatibility with import assertions. Since this is a peer dependency, consumers must switch plugins to match. 🌎 External changes: - Export JavaScript configuration as `configuration/javascript`. - Export TypeScript configuration as `configuration/typescript` now that microsoft/TypeScript#48665 has been fixed. - Update README with instructions on how to consume Babel, ESLint, JavaScript, rollup.js, and TypeScript configurations. 🏠 Internal changes: - Clean up `package.json` scripts and remove `engines` field. 🧹 Chores: - Upgrade dependencies.
⚠️ BREAKING CHANGES (if using lint rules): - Transition from deprecated `@babel/plugin-syntax-import-assertions` to the new `@babel/plugin-syntax-import-attributes` and enable option `deprecatedAssertSyntax` for backward compatibility with import assertions. Since this is a peer dependency, consumers must switch plugins to match. 🌎 External changes: - Export JavaScript configuration as `configuration/javascript`. - Export TypeScript configuration as `configuration/typescript` now that microsoft/TypeScript#48665 has been fixed. - Update README with instructions on how to consume Babel, ESLint, JavaScript, rollup.js, and TypeScript configurations. 🏠 Internal changes: - Clean up `package.json` scripts and remove `engines` field. 🧹 Chores: - Upgrade dependencies.
Bug Report
🔎 Search Terms
tsconfig, exports, extends
🕗 Version & Regression Information
I encountered this issue in version
[email protected]
.Error description
You can use the tsconfig.json extends field to inherit configuration options from another tsconfig file. The base tsconfig file can be located in another package, like demonstrated here.
🙁 Actual behavior
Let's say I'm in package
my-app
, which contains a tsconfig with"extends": "my-lib/tsconfig-base.json
. Typescript ignores the exports field of packagemy-lib
. It will always look for a filetsconfig-base.json
in the my-lib root directory, even if an "exports" mapping exists for this name.🙂 Expected behavior
I expected Typescript to use the standard node resolution algorithm when looking up the tsconfig file on disk, which respects the "exports" field.
The text was updated successfully, but these errors were encountered: