Skip to content

tsconfig.json extends field node-style resolution broken #43245

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

Open
achingbrain opened this issue Mar 15, 2021 · 4 comments
Open

tsconfig.json extends field node-style resolution broken #43245

achingbrain opened this issue Mar 15, 2021 · 4 comments
Labels
Docs The issue relates to how you learn TypeScript

Comments

@achingbrain
Copy link

Bug Report

The docs say (emphasis mine):

The value of extends is a string which contains a path to another configuration file to inherit from. The path may use Node.js style resolution.

This worked up until recently but is currently broken. I can't pin down a specific version where it stopped working as I guess the code that loads the config may be from a dependency of typescript that is shared across different versions.

We've got a module that contains org-wide tsconfig that we want our projects to extend - they could be regular modules, monorepo packages, etc.

Those projects can and do get pulled in as github urls (or https://gitpkg.now.sh/ urls for monorepo packages) for other modules as dependencies during PRs. Those projects are typically written in js but generate types from jsdoc comments using the npm prepare script for the current module to use, which now fails as it can't resolve the extends path.

You can't always predict which node_modules folder will contain the relevant dependency, so doing Node.js style resolution (e.g. stepping up through directories) is essential for our use-case.

🔎 Search Terms

  • tsconfig extending npm package
  • tsconfig extend node_modules
  • tsconfig node_modules
  • tsconfig extend resolve

🕗 Version & Regression Information

Not sure, it was working before Christmas, now it does not.

🙁 Actual behavior

Typescript does not resolve the extends path using Node.js style resolution.

🙂 Expected behavior

Typescript should resolve the extends path using Node.js style resolution.

References:

#18865
#30701

@RyanCavanaugh RyanCavanaugh added the Needs More Info The issue still hasn't been fully clarified label Mar 15, 2021
@RyanCavanaugh
Copy link
Member

Please include a setup that reproduces the problem.

@achingbrain
Copy link
Author

I think I've figured out what's happening.

The shared config is in the aegir module under src/config/tsconfig.aegir.json.

It's specified in extending tsconfig.json files as:

{
  "extends": "aegir/src/config/tsconfig.aegir.json",  <-- does not work
  // .. other stuff
}

Or alternatively:

{
  "extends": "./node_modules/aegir/src/config/tsconfig.aegir.json",  <-- works
  // .. other stuff
}

Aegir uses typesVersions in it's package.json to direct tsc to the ./dist folder where the generated types are published:

"typesVersions": {
  "*": {
    "utils/*": [
      "dist/utils/*"
    ],
    "src/*": [
      "dist/src/*",
      "dist/src/*/index"
    ],
    "src/": [
      "dist/src/index"
    ]
  }
}

The tsconfig file is not copied to dist during building but it looks like tsc is using the typesVersions field to override where it loads the config file from.

If I copy the config file into dist/src/config or if I modify the typesVersions field as below it starts to work:

"typesVersions": {
  // .. other fields
  "src/config/tsconfig.aegir.json": [
    "src/config/tsconfig.aegir.json"
  ]
}

Which I guess is fair enough, I can see why you might want different config files for different ts versions, though the docs only mention loading .d.ts files from locations specified in typesVersions.

@RyanCavanaugh RyanCavanaugh added Docs The issue relates to how you learn TypeScript and removed Needs More Info The issue still hasn't been fully clarified labels Mar 16, 2021
@RyanCavanaugh
Copy link
Member

The interaction here wasn't really intentional to be honest, but in retrospect is needed -- compiler options in tsconfig doesn't allow extra properties, so if you used a setting from a newer version of TS you'd have to set up typesVersions. We should add this to the docs, somewhere.

@achingbrain
Copy link
Author

Ok, feel free to close this issue if it's not useful keeping open, my problem is resolved.

achingbrain added a commit to ipfs/aegir that referenced this issue Mar 17, 2021
Otherwise resolution of the shared config fails during tsc compilation
without an explicit path to the file in your `node_modules` folder which
means the workflow of using gitpkg.now.sh to depend on monorepo packages
in PRs is completely broken if they have a prepare step or any other use
of typescript.

This is one solution, another would be to copy tsconfig.aegir.json to
the `dist` folder during a build, I have no opinion on which is better.

Refs: microsoft/TypeScript#43245
hugomrdias pushed a commit to ipfs/aegir that referenced this issue Mar 17, 2021
Otherwise resolution of the shared config fails during tsc compilation
without an explicit path to the file in your `node_modules` folder which
means the workflow of using gitpkg.now.sh to depend on monorepo packages
in PRs is completely broken if they have a prepare step or any other use
of typescript.

This is one solution, another would be to copy tsconfig.aegir.json to
the `dist` folder during a build, I have no opinion on which is better.

Refs: microsoft/TypeScript#43245
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Docs The issue relates to how you learn TypeScript
Projects
None yet
Development

No branches or pull requests

2 participants