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.

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

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

Closed
sanderson-ut opened this issue Sep 28, 2022 · 7 comments
Closed

Comments

@sanderson-ut
Copy link
Contributor

sanderson-ut commented Sep 28, 2022

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 #187 for a suggested fix

@JounQin
Copy link
Collaborator

JounQin commented Sep 28, 2022

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.

@sanderson-ut
Copy link
Contributor Author

sanderson-ut commented Sep 29, 2022

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
Copy link
Contributor Author

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

@JounQin
Copy link
Collaborator

JounQin commented Oct 3, 2022

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
Copy link
Collaborator

JounQin commented Oct 11, 2022

@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.

@sanderson-ut
Copy link
Contributor Author

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.

@JounQin
Copy link
Collaborator

JounQin commented Oct 20, 2022

close via #187

@JounQin JounQin closed this as completed Oct 20, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

2 participants