-
-
Notifications
You must be signed in to change notification settings - Fork 428
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
Enabling enhanced-resolve
Causes Errors
#1507
Comments
Sadly, I could only boil this down to 2 resolve-processes which had different results, so we might have a tough time working out what we have to change. Resolve-Calls (using
|
Resolve Base | enhanced-resolve result |
typescript result |
actual result | desired result |
---|---|---|---|---|
./node_modules/spica/global.ts |
./global.type.ts |
undefined |
"./node_modules/spica/global.type.ts" |
undefined |
. |
./index.ts |
"./index.d.ts" |
"./index.ts" |
"./index.d.ts" |
The desired result is taken from taken from ts-loader@9.3
.
Case 1:
-
spica/global.ts
has been imported. -
spica/global.ts
, then again, imports./global.type.ts
. -
typescript
only resolves module specifiers which have their output extension (such as.js
) or no extension. -
enhanced-resolve
doesn't care about the file extension being.ts
and finds theglobal.type.ts
file
Case 2:
This is taken from https://github.com/falsandtru/pjax-api/tree/76ad3769e23497a15817914a92787089c5dfa8cc
-
The specifier
.
points to the directory containing thepackage.json
file. -
typescript
looks for the types referenced in thepackage.json
file'stypes
orexports
field and thus finds theindex.d.ts
file -
enhanced-resolve
can't find themain
file becuause the package is not compiled. Thus, it searches for files with the configured extensions and finds theindex.ts
file
Questions
- Is there ever a situation where
enhanced-resolve
should be prioritized?alias
setting
- How do we know
enhanced-resolve
s result should be prioritized higher thantypescript
s? As it looks,enhanced-resolve
tends to return incorrect, undesired results.
As you say,
Maybe the answer is we're only interested if a typescript lookup has failed? |
So my idea based on this is the following:
Because of the result being That way we can be sure all results are returned for the sake of the |
Sounds like an interesting idea. I'm wondering what effect this might have on performance - hopefully not too significant. Feels like it could work. Question: if the enhanced-resolve has been missing in action for all this time, what have been the issues that has caused? Are there use cases we haven't been supporting as a consequence? Essentially, what changes if we do this? What do we gain? |
Not sure, tbh - I thought |
I just gave it a go and it does work. Sadly, replacing it with Do you think we should completely drop it? |
Or we could just leave it as-is which will make it easier to implement |
At the moment I'm inclined to leave as is. The surprising thing is that a "broken" enhanced-resolve doesn't seem to be an issue. It doesn't seem to be impacting users. I am curious as to the impact on the comparison tests of the new approach. If you have the bandwidth, I'd be curious to see what that looks like. But no worries if not |
Currently, I will quickly set up a PR containing a (part-wise) re-enabled |
The changes which happen when enabling You might want to have a look at it: #1509 |
That's the direction I'm thinking as well |
Expected Behaviour
Running
webpack
usingts-loader
withenhanced-resolve
enabled causes errors as described in #1504 and #1505.Actual Behaviour
webpack
should still run properly withts-loader
.Steps to Reproduce the Problem
ts-loader@9.4.0
spica
setTimeout
fromspica/global
webpack
withts-loader
Location of a Minimal Repository that Demonstrates the Issue.
Thanks a lot to @falsandtru for providing the demonstrations!
This issue is related to #1506, #1504 and #1505
The error has been introduced in #1503
The text was updated successfully, but these errors were encountered: