-
-
Notifications
You must be signed in to change notification settings - Fork 433
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
Ts-loader never uses enhanced-resolve as of enhanced-resolve v5.3.1 #1492
Comments
Hi @johnnyreilly . Thanks for this awesome project! Let me know if you would want me to look into this/create a pull request for this. |
Yes please! I'm going to be on holiday here and there over the next couple of weeks and so might not be too responsive. Do you fancy raising a prospective PR and we can see where we go with it? |
Hi @johnnyreilly . Okay will do! Might only be able to get to it at the end of the week/early next week though. Hope that works? |
Whenever you like ! - I'm only going to be online sporadically until September anyway |
Okay, great. Will do! Enjoy the break 👌 |
Hi @johnnyreilly . Just to update you. Things have been a bit manic my side, and I have not had time to properly look at this. Things should ease up around month end/early October though. Should be able to work on it then. |
No worries! |
When resolving modules attempts are first made to use enhanced-resolver (which is also used by webpack), and if that fails we fallback to the typescript resolver (src/servicesHost.ts:resolveModule ). In doing this
undefined
is passed as the context to the enhanced-resolver'sresolveSync
method.Prior to version 5.3.1 the context value was not validated, as opposed to v5.3.1 onward (see webpack/enhanced-resolve#261), of which the first check is to see if it's an object or not. This results in a error being throw, of which this is handled silently (see
ts-loader/src/servicesHost.ts
Line 1270 in b4b0363
This means enhanced-resolve is never used, of which this is hard to pick up as we handle all error silently and fallback to the typescript resolver.
Expected Behaviour
To use enhanced-resolve when resolving modules.
Actual Behaviour
The enhanced resolver is never used when resolving modules, and falls back to the typescript resolver.
Steps to Reproduce the Problem
Try to use a custom fileSystem, by specifying this in your webpack's resolve options. Rather than this option being passed on to the enhanced-resolver , it is neglected, meaning that ts-loader falls back to the default/standard typescript filesystem. This is highlighted by the snippet code below (or in the example project below)
webpack.config.js
index.ts
Expected Output (running
npx webpack
andnode dist/main.js
)"Using memory fileSystem"
Actual Output (running
npx webpack
)TS2307: Cannot find module './fileSystemType' or its corresponding type declarations.
Location of a Minimal Repository that Demonstrates the Issue.
https://github.com/walisc/ts-loader-enhance-resolver-bug
Proposed Fix
Passing an empty object as opposed to undefined, to resolveSync. In addition, it would be good to distinguish between configuration errors and actual resolve errors. In the snippet below I do this through a resolver plugin. Do note, this is just a poc, and maybe more work /cleaning up might be required.
The text was updated successfully, but these errors were encountered: