Skip to content
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.

Sign up for GitHub

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

Jump to bottom

tsconfig "extends" field ignores "exports" field of source package #48665

Closed
pschiffmann opened this issue Apr 13, 2022 · 1 comment · Fixed by #50955
Closed

tsconfig "extends" field ignores "exports" field of source package #48665

pschiffmann opened this issue Apr 13, 2022 · 1 comment · Fixed by #50955
Labels
Effort: Moderate Requires experience with the TypeScript codebase, but feasible. Harder than "Effort: Casual". Experience Enhancement Noncontroversial enhancements Help Wanted You can do this Suggestion An idea for TypeScript

Comments

@pschiffmann
Copy link

Bug Report

🔎 Search Terms

tsconfig, exports, extends

🕗 Version & Regression Information

I encountered this issue in version typescript@4.7.0-dev.20220408.

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 package my-lib. It will always look for a file tsconfig-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.
@weswigham weswigham added the Experience Enhancement Noncontroversial enhancements label Apr 13, 2022
@weswigham
Copy link
Member

getExtendsConfigPath in commandLineParser.ts is currently using nodeModuleNameResolver and passing { moduleResolution: ModuleResolutionKind.NodeJs } - it should just need to be swapped to nodeNextModuleNameResolver and pass { moduleResolution: ModuleResolutionKind.NodeNext }, and hopefully it should just work. Definitely needs some tests to check that tsconfig.json documents resolve through exports when searched for in this way, though, since it hasn;t been utilized with that Extensions set much yet. Should be an easy change for anyone to make~

@weswigham weswigham added Help Wanted You can do this Effort: Moderate Requires experience with the TypeScript codebase, but feasible. Harder than "Effort: Casual". labels Apr 13, 2022
@RyanCavanaugh RyanCavanaugh added the Suggestion An idea for TypeScript label Apr 20, 2022
agilgur5 added a commit to agilgur5/tsconfig that referenced this issue May 21, 2022
@agilgur5
fix(docs): package.json#exports doesn't work for tsconfig extends yet
1aa85aa 
- see TS issue: microsoft/TypeScript#48665
@agilgur5 agilgur5 mentioned this issue Jun 13, 2022
Merged
agilgur5 added a commit to agilgur5/ts-library-base that referenced this issue Jun 14, 2022
@agilgur5
deps: use @agilgur5/tsconfig to simplify tsconfig
be0922a 
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)
nchevsky added a commit to nchevsky/bitumen that referenced this issue Sep 11, 2022
@nchevsky
v0.1.1: Include tsconfig.json in package
ac0c984 
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
nchevsky added a commit to nchevsky/bitumen that referenced this issue Sep 11, 2022
@nchevsky
v0.1.1: Include tsconfig.json in package
0022913 
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
@a-tarasyuk a-tarasyuk mentioned this issue Sep 26, 2022
Merged
@jackw jackw mentioned this issue Sep 28, 2022
Merged
@andrewbranch andrewbranch mentioned this issue Mar 20, 2023
Closed
nchevsky added a commit to nchevsky/bitumen that referenced this issue Jun 12, 2023
@nchevsky
v1.0.0: Add JS/TS configuration exports; switch Babel plugins
b807c5e 
⚠️ 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.
nchevsky added a commit to nchevsky/bitumen that referenced this issue Jun 12, 2023
@nchevsky
v1.0.0: Add JS/TS configuration exports; switch Babel plugins
ed9cd01 
⚠️ 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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Effort: Moderate Requires experience with the TypeScript codebase, but feasible. Harder than "Effort: Casual". Experience Enhancement Noncontroversial enhancements Help Wanted You can do this Suggestion An idea for TypeScript
Projects
None yet
Milestone
No milestone
3 participants
@weswigham @RyanCavanaugh @pschiffmann