Issue: not resolving paths on tsconfig for next.js projects

[toni-monteagudo]

Expected Behavior

Current Behavior

By default, next.js generates a tsconfig.json like this, without baseURL:

{
  "compilerOptions": {
    "target": "es5",
    "lib": ["dom", "dom.iterable", "esnext"],
    "allowJs": true,
    "skipLibCheck": true,
    "strict": true,
    "forceConsistentCasingInFileNames": true,
    "noEmit": true,
    "esModuleInterop": true,
    "module": "esnext",
    "moduleResolution": "node",
    "resolveJsonModule": true,
    "isolatedModules": true,
    "jsx": "preserve",
    "incremental": true,
    "plugins": [
      {
        "name": "next"
      }
    ],
    "paths": {
      "@/*": ["./*"]
    }
  },
  "include": ["next-env.d.ts", "**/*.ts", "**/*.tsx", ".next/types/**/*.ts"],
  "exclude": ["node_modules"]
}

When using TypeScript in a project without the baseUrl property in the tsconfig.json file, there is a problem with resolving file paths when running the analysis with dependency-cruiser. The file paths are not resolved correctly, leading to inaccurate dependency analysis.

This is the method: https://github.com/sverweij/dependency-cruiser/blob/main/src/main/resolve-options/normalize.mjs#L66C10-L66C33

Possible Solution

One possible solution to address this issue is to update the documentation of dependency-cruiser to provide clearer instructions on how to handle the absence of the baseUrl property in the tsconfig.json file. This would help users understand the impact of not setting the baseUrl and provide guidance on how to resolve file path issues when using TypeScript without baseUrl.

Steps to Reproduce (for bugs)

Create a new TypeScript project without setting the baseUrl property in the tsconfig.json file.
Run the dependency-cruiser analysis on the project.
Observe that the file path resolution is not accurate, leading to incorrect dependency analysis.

Your Environment

• Version used: 13.0.4
• Next.js version: 13.4.7
• Node version: v18.16.0
• Operating System and version: MacOsX Monterrey
• Link to your project: Private

[sverweij]

Hi @toni-monteagudo thank you for reporting this - and for the research you put into it - I really appreciate that!

It turns out the basePath was mandatory for TypeScript itself to handle paths up to version 4.1. As of that version it's recommended to not use the basePath at all. I recall introducing the piece of code(& accompanying comment) to because tsconfig-paths-webpack-plugin/ tsconfig-paths-webpack-plugin required it as well - and refused to apply itself with messages that'd look inexplicable to dependency-cruiser users.

I've checked (by removing the check) - and tsconfig-paths still does this in its latest version (and using the latest version of TypeScript), which one could argue to be a bug as it's not consistent anymore with how recent versions of TypeScript operate:

tsconfig-paths-webpack-plugin: Found no baseUrl in tsconfig.json, not applying tsconfig-paths-webpack-plugin

It seems the tsconfig-paths-webpack-plugin authors tend to agree with this: tsconfig-paths-webpack-plugin#99.

fixing this

Documenting this behavior is certainly an option - but just adding the (unrecommended) baseUrl option to a tsconfig to make tsconfig-paths/ dependency-cruiser work doesn't feel entirely right. Configuring TypeScript projects is hard enough as it is.

In stead it'd be ideal if the tsconfig-paths(-webpack-plugin) wouldn't need it anymore either. If I can find the energy for it I'll see if I can take a stab at raising a PR over there.

Alternatively (and probably quicker), I can implement a workaround in dependency-cruiser:

• remove the baseUrl existence check
• if the baseUrl doesn't exist, add a default ("baseUrl": "./" seems to be reasonable) to the config passed to the resolve options until a fix for tsconfig-paths-webpack-plugin#99 has landed.

[sverweij]

Hi @toni-monteagudo the update on tsconfig-paths-webpack-plugin didn't seem too hard to do so I've made a pull request on the project: tsconfig-paths-webpack-plugin #105.

Updates on dependency-cruiser will follow (both in parallel to the time it takes to land the above PR & another one after).

[sverweij]

hi again @toni-monteagudo dependency-cruiser@13.0.5 (just released) contains the fix for this issue, which works independent of the the patch to the tsconfig-paths-webpack-plugin.

[toni-monteagudo]

Hi @sverweij ! Woah! This is awesome! Thanks for this quick update 😄 . I would update my project right now!

It's a pleasure to work with people who maintain their projects so well. Thank you very much!

[toni-monteagudo]

Works like a charm! :)