Skip to content

Experiment with adding webpack 4 support back#1697

Open
Copilot wants to merge 59 commits into
mainfrom
copilot/support-webpack-4-and-5
Open

Experiment with adding webpack 4 support back#1697
Copilot wants to merge 59 commits into
mainfrom
copilot/support-webpack-4-and-5

Conversation

Copy link
Copy Markdown

Copilot AI commented May 21, 2026

  • Identify actionable new @copilot comments
  • Enumerate src/**/*.ts files changed in this PR
  • Review changed TypeScript code for potential performance regressions
  • Summarize findings (including if none) with concrete file references
  • Reply on PR comment with review results

Agent-Logs-Url: https://github.com/TypeStrong/ts-loader/sessions/74b74f2d-76ad-4022-9635-77d0c5acce76

Co-authored-by: johnnyreilly <1010525+johnnyreilly@users.noreply.github.com>
Agent-Logs-Url: https://github.com/TypeStrong/ts-loader/sessions/e322b7ed-e010-4d60-9a2d-3672c9d55324

Co-authored-by: johnnyreilly <1010525+johnnyreilly@users.noreply.github.com>
@johnnyreilly
Copy link
Copy Markdown
Member

@copilot please consistently use instance.isWebpack5 to decide strategy

@johnnyreilly johnnyreilly changed the title Align webpack support metadata with current CI coverage Experiment with adding webpack 4 support back May 21, 2026
Copy link
Copy Markdown
Author

Copilot AI commented May 21, 2026

@copilot please consistently use instance.isWebpack5 to decide strategy

Done in 5d7ab2f. I updated the remaining strategy checks to consistently branch on instance.isWebpack5 (including cached/reused instance paths and build-dependency registration) rather than using direct feature detection at those decision points.

Comment thread src/utils.ts Outdated
} from './interfaces';
import { getInputFileNameFromOutput } from './instances';

export const isWebpack5 = !!(webpack as any).sources;
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this necessary @copilot?

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copilot AI requested a review from johnnyreilly May 21, 2026 19:51
Comment thread src/after-compile.ts Outdated
(error: any) => error.loaderSource !== tsLoaderSource(loaderOptions)
)
.forEach(error => module.addError(error));
const webpackModule = module as any;
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@copilot I don't think the webpack5 code needs to use webpackModule it can use module

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updated in 7b3cd3e — webpack 5 path now uses module directly (getWarnings/getErrors/clearWarningsAndErrors) and keeps webpackModule only for the webpack 4 branch.

Copy link
Copy Markdown
Author

Copilot AI commented May 21, 2026

@copilot please consistently use instance.isWebpack5 to decide strategy

Handled in 5d7ab2f and retained in follow-ups: strategy decisions branch on instance.isWebpack5 consistently.

Copilot AI requested a review from johnnyreilly May 21, 2026 20:12
@johnnyreilly
Copy link
Copy Markdown
Member

@copilot yarn comparison-tests --single-test nodeModulesMeaningfulErrorWhenImportingTs succeeds on my machine but fails in CI - please investigate

Copy link
Copy Markdown
Author

Copilot AI commented May 24, 2026

@copilot yarn comparison-tests --single-test nodeModulesMeaningfulErrorWhenImportingTs succeeds on my machine but fails in CI - please investigate

Investigated and fixed in 7e6d119. CI logs showed nodeModulesMeaningfulErrorWhenImportingTs failing on output normalization around module error attribution. I updated after-compile to use runtime module capabilities when determining module resource/error paths (instead of assuming a single webpack API shape), and tagged the no-output loader error in index.ts so ts-loader-owned module errors are consistently filtered/re-added. I re-ran yarn build, yarn lint, and yarn comparison-tests -- --single-test nodeModulesMeaningfulErrorWhenImportingTs (plus errors) successfully.

@johnnyreilly
Copy link
Copy Markdown
Member

@copilot after the last commit all yarn comparison-tests are failing

Copy link
Copy Markdown
Author

Copilot AI commented May 24, 2026

@copilot after the last commit all yarn comparison-tests are failing

Fixed in 90b2860. I checked the failing CI jobs and they were failing before test execution with TS2416 type errors from @types/eslint-scope after the last lockfile change. I restored the prior lockfile resolution (the last commit had collapsed @types/eslint@*), which unblocked comparison test compilation. I then re-ran yarn build, yarn lint, yarn comparison-tests -- --single-test errors, and yarn comparison-tests -- --single-test nodeModulesMeaningfulErrorWhenImportingTs successfully.

@johnnyreilly
Copy link
Copy Markdown
Member

Starting to write this up here: johnnyreilly/blog.johnnyreilly.com#1109

@johnnyreilly
Copy link
Copy Markdown
Member

@copilot review the src/**.*ts files in this PR with an eye to identifying any potential performance issues this PR could introduce. There may be none. Tell me what issues might exist. Make no changes - let me decide.

Copy link
Copy Markdown
Author

Copilot AI commented May 25, 2026

@copilot review the src/**.*ts files in this PR with an eye to identifying any potential performance issues this PR could introduce. There may be none. Tell me what issues might exist. Make no ch...

Reviewed at 06def35 with a performance-focused pass over src/**/*.ts changes in this PR. I don’t see any high-confidence new perf regressions.

Possible low-risk hotspots to keep an eye on:

  • src/after-compile.ts:131-146 (determineModules): now also checks resourceResolveData?.path; this may increase modules considered in the map in some builds.
  • src/watch-run.ts:42-49 (timestamp normalization): extra per-file branching on each watch cycle; likely negligible, but it is new work on very large file sets.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants