"Unable to resolve path to module" in monorepo, after Angular 13 upgrade
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
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.
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.
Hi @JounQin - did you get a chance to look at this?
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.
@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.
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.
close via #187