eslint-import-resolver-typescript icon indicating copy to clipboard operation
eslint-import-resolver-typescript copied to clipboard

"Unable to resolve path to module" in monorepo, after Angular 13 upgrade

Open sanderson-ut opened this issue 3 years ago • 5 comments

After upgrading to Angular 13, which only supports Angular Package Format and ESModules, we are seeing "Unable to resolve path to module" issues.

Our code is a monorepo using Yarn Workspaces, with TSConfig path aliases set up to point to the built assets of our library packages, so @foo/bar is set up to resolve to the directory node_modules/@foo/bar/dist, which contains a package.json file, a type definition file called foo-bar.d.ts and folders for built assets. The package.json file in the built assets contains a typings entry, that references foo-bar.d.ts.

The issue is that getMappedPath only looks for files, not directories. If this line is removed, or a check is added for a directory as well as a file, then the mapped path is the folder containing the library, and enhanced-resolve correctly resolves the module and its types as it parses the typings key inside package.json.

See https://github.com/import-js/eslint-import-resolver-typescript/pull/187 for a suggested fix

sanderson-ut avatar Sep 28 '22 12:09 sanderson-ut

Thanks for issue first, can you provide a minimal reproduction with ng-cli maybe first? I'm also using Angular 13+, but didn't meet this problem. So I need to confirm and understand the root cause first.

JounQin avatar Sep 28 '22 12:09 JounQin

Hi @JounQin - I've created a repro monorepo app: https://github.com/scott-ut/eslint-import-resolver-typescript-repro

There are instructions in the readme. I think Angular 13 might have been a red herring as the APF removes certain default fields inside the /dist/package.json file which eslint-import-resolver-typescript fell back to. If you rename the typedef file from baz.d.ts to index.d.ts then it is picked up.

Maybe a clean solution would be to look for typings inside package.json, instead of simply the presence of a file itself, however I think the downstream resolvers handle this.

sanderson-ut avatar Sep 29 '22 10:09 sanderson-ut

Hi @JounQin - did you get a chance to look at this?

sanderson-ut avatar Oct 03 '22 16:10 sanderson-ut

Hi @JounQin - did you get a chance to look at this?

Sorry I'm on a vocation recently, I'll take a look when I'm free.

JounQin avatar Oct 03 '22 23:10 JounQin

@scott-ut I think you should use:

    "paths": {
      "@foo/bar": [
-       "../../node_modules/@foo/bar/dist/baz" 
+       "../bar/projects/baz/src/public-api.ts"
      ]
    }

So that the lint command will not require build first.

But the PR's change seems correct to me at the same time.

JounQin avatar Oct 11 '22 02:10 JounQin

Thanks - we want to use the built, dist output instead of the src output to make it easier for us to decompose the monorepo into separate repos later if we decide to and so that we can use the same tsconfig aliases for build, lint and test. I've updated the PR with your suggestion.

sanderson-ut avatar Oct 19 '22 10:10 sanderson-ut

close via #187

JounQin avatar Oct 20 '22 12:10 JounQin