feat: add webpack 4 support to ts-loader v9#1697
Conversation
|
@copilot please consistently use |
Done in 5d7ab2f. I updated the remaining strategy checks to consistently branch on |
| } from './interfaces'; | ||
| import { getInputFileNameFromOutput } from './instances'; | ||
|
|
||
| export const isWebpack5 = !!(webpack as any).sources; |
There was a problem hiding this comment.
Good catch — no, it wasn’t necessary there. I removed isWebpack5 from utils.ts and localized detection to instance setup in instances.ts in 78fa91f, so strategy still flows through instance.isWebpack5 without the extra utils export.
| (error: any) => error.loaderSource !== tsLoaderSource(loaderOptions) | ||
| ) | ||
| .forEach(error => module.addError(error)); | ||
| const webpackModule = module as any; |
There was a problem hiding this comment.
@copilot I don't think the webpack5 code needs to use webpackModule it can use module
There was a problem hiding this comment.
Updated in 7b3cd3e — webpack 5 path now uses module directly (getWarnings/getErrors/clearWarningsAndErrors) and keeps webpackModule only for the webpack 4 branch.
|
Starting to write this up here: johnnyreilly/blog.johnnyreilly.com#1109 |
|
@copilot review the |
Reviewed at Possible low-risk hotspots to keep an eye on:
Everything else I reviewed looks neutral or slightly better for runtime cost (no obvious new heavy loops/allocations in hot paths). No code changes made. |
|
@copilot please review this PR and give me your thoughts |
My review on Overall this is in good shape and I think the webpack 4 support direction is sound. The latest branch CI I checked for this head is green ( What looks strong:
Things I’d keep an eye on before merge:
I don’t see a clear blocker in the current state. |
|
@copilot a tester reported this issue:
Can you identify where that might have come from? |
Uh oh!
There was an error while loading. Please reload this page.