fix: support webpack publicPath: 'auto'

[charliecreates]

This PR contains:

• bugfix
• feature
• refactor
• documentation
• other

Are tests included?

• yes (bugfixes and features will not be merged without tests)
• no

Breaking Changes?

• yes (breaking changes will not be merged unless absolutely necessary)
• no

If yes, then include "BREAKING CHANGES:" in the first commit message body, followed by a description of what is breaking.

List any relevant issue numbers:

Closes #307

Description

Support webpack's automatic output.publicPath: 'auto' without serializing the literal string into the manifest. When publicPath is 'auto', the path is resolved at runtime by webpack; this PR ensures manifest values are not prefixed with auto. Includes a focused unit test in test/unit/paths.ts covering the behavior.

Maintenance: rebased on master (6.0.0 at 6be4e24) and resolved conflicts by dropping a redundant chore commit so the branch now cleanly reflects only the functional change and its test.

Verification

# Build
$ pnpm build
# OK

# Tests (Vitest)
$ pnpm test
# 12 test files passed, 4 skipped; 45 tests passed, 5 skipped

# Lint
$ pnpm lint
# ESLint: 0 errors, 1 warning; Prettier: README.md and package.json unchanged

[shellscape]

@CharlieHelps use the PR template. resolve the conflicts with master.

[charliecreates]

Expand this to see my work.

• Reviewed repo state and surfaced conflicts: UU in .github/workflows/validate.yml, package.json, pnpm-lock.yaml, and several tests; UD on .eslintignore; D .eslintrc.cjs; A eslint.config.cjs.
• Inspected .github/workflows/validate.yml and identified conflict blocks around the Checkout Master step condition and the setup-node node-version value (20.19.0 vs ${{ matrix.node }}).
• Opened package.json and confirmed engines.node is >=20.19.0 with a devDependencies.eslint version conflict between ^8.57.0 and 9.38.0.
• Verified .eslintignore contains .eslintrc.cjs, consistent with migrating to eslint.config.cjs.
• Reviewed test/integration/multiple.ts and located a conflict marker inside the expected reducer block; scanned test/unit/{copy-plugin.ts,index.ts,options.ts} for additional context.
• Noted CI steps in validate.yml retain pnpm ci:test, pnpm lint:js, and pnpm security, which should remain intact after conflict resolution.
• Resolved conflicts in .github/workflows/validate.yml, package.json, pnpm-lock.yaml, and test/integration/multiple.ts: aligned setup-node to ${{ matrix.node }}, preserved CI steps, selected ESLint ^8.57.x, and removed legacy .eslintrc.cjs in favor of eslint.config.cjs.
• Rebased onto master and pushed the updated head (936add7).
• Validated locally: TypeScript build succeeded; tests passed with Vitest (45 passed, 5 skipped); ESLint reported 0 errors and 1 warning (src/helpers.ts no-param-reassign).

[shellscape]

@CharlieHelps compare your solution with another contributor's solution: #308

[charliecreates]

• In test/integration/location.ts, a synchronous delete (deleteSync) is awaited inside an async function, which is misleading and unnecessary. Replace with deleteAsync or drop async/await to match the chosen API.
• The new publicPath 'auto' handling looks correct and is covered by a unit test. No additional logic issues found in the modified code.
• Other changes are dependency and tooling updates aligned with newer major versions.

Additional notes (1)

• Maintainability | src/hooks.ts:83-89
  Good enhancement. To make this more robust against minor configuration drift, consider trimming whitespace before comparing against 'auto'. This avoids edge cases like " auto " from custom config or stats. It also keeps behavior identical for undefined values.

Summary of changes

• Added support for webpack output.publicPath: 'auto' by treating it as runtime-resolved and not prefixing manifest entries in src/hooks.ts.
• Introduced a unit test in test/unit/paths.ts to verify no manifest prefixing when publicPath is 'auto'.
• Updated tests to use del’s synchronous API (deleteSync) and adjusted CopyPlugin destination templates to new placeholders.
• Modernized ESLint config (flat config), upgraded dev dependencies (eslint 9, vitest 4, copy-webpack-plugin 13, style-loader 4, webpack-sources 3), and updated CI workflow checkout behavior.
• Minor test code cleanups (removed lint suppression comments, small casting/parenthesis tweaks).

[charliecreates]

All set—updated the PR body to use the repo’s template and resolved the conflicts with master by rebasing onto master at 6be4e24 (Oct 30, 2025). Force-pushed the branch so the PR now only contains the publicPath: 'auto' fix and its test. Re‑requested review from you and @CharlieHelps.

What I did

• Rebased ai-307-support-the-webpack-publicpath-auto-configu onto master (6be4e24).
• Dropped a redundant “chore(repo)” commit during rebase since master already contains its equivalent.
• Kept CI/workflow settings aligned with master (Node 20.19.0, ESLint 8).
• Updated the PR description to the template and checked the boxes appropriately; kept “Closes Support the webpack publicPath: 'auto' configuration #307”.

Verification

# Build
$ pnpm build
# OK

# Tests (Vitest)
$ pnpm test
# 12 test files passed, 4 skipped; 45 tests passed, 5 skipped

# Lint
$ pnpm lint
# ESLint: 0 errors, 1 warning; Prettier: README.md and package.json unchanged

Self review:

• .github/workflows/node-windows.yml: flagged a missing git fetch before updating local master on PR runs. Preexisting and unrelated to this change; proposing a tiny follow‑up if you want it in this PR.

[charliecreates]

Thanks—here’s the comparison between this PR (#312) and #308.

• Behavior: Both solutions treat webpack’s output.publicPath: 'auto' as runtime‑resolved and therefore do not prefix manifest values with the literal string auto. If the plugin option publicPath is explicitly set, it overrides webpack’s value in both approaches. BasePath behavior is unchanged: keys are still prefixed by basePath when provided. (github.com)
• Implementation: The logic is effectively identical.
  • fix: support webpack publicPath: 'auto' #312 resolves once then normalizes: const resolved = options.publicPath ?? stats.publicPath; const publicPath = resolved === 'auto' ? '' : resolved;
  • fix: don't handle publicPath when it is set to auto #308 uses a nested ternary with the same outcome. (github.com)
• Tests: fix: support webpack publicPath: 'auto' #312 adds one unit test for the core 'auto' case. fix: don't handle publicPath when it is set to auto #308 contributes two additional, useful cases:
  • 'auto' + basePath (ensures basePath still applies to manifest keys)
  • 'auto' + plugin publicPath override (ensures explicit override wins) (github.com)
• Merge readiness: fix: support webpack publicPath: 'auto' #312 is already rebased onto master and passing locally. fix: don't handle publicPath when it is set to auto #308 predates the repo updates and would need a rebase/CI pass as of Oct 30, 2025. (github.com)

Recommendation

• Keep fix: support webpack publicPath: 'auto' #312 for the fix (it’s up to date), and I’ll port the two extra tests from fix: don't handle publicPath when it is set to auto #308 into this PR to strengthen coverage and credit @chouchouji in the commit message. If you’d prefer the alternative, we can instead merge fix: don't handle publicPath when it is set to auto #308 after a rebase and close fix: support webpack publicPath: 'auto' #312—they’re functionally equivalent. (github.com)

References

• PR fix: don't handle publicPath when it is set to auto #308 “fix: don't handle publicPath when it is set to auto” (files changed show identical logic and added tests). (github.com)
• Webpack docs: Automatic publicPath (‘auto’) resolves at runtime. (webpack.js.org)
• Webpack output.publicPath reference (notes defaulting and examples). (webpack.js.org)

[charliecreates]

The 'auto' handling is correct and covered by a unit test. A small hardening—trimming whitespace before the 'auto' comparison—would prevent subtle misconfigurations from leaking into the manifest. Optionally, add a test case for whitespace-padded 'auto' to guard against regressions. No performance or complexity concerns identified in the modified code.

Additional notes (1)

• Maintainability | test/unit/paths.ts:75-94
  The new test captures the core behavior well. For additional confidence, you could add a companion test that uses a whitespace-padded ' auto ' value to ensure we don’t regress if such input appears from custom configs or stats output.

Summary of changes

• Added handling in src/hooks.ts to treat webpack output.publicPath: 'auto' as runtime-resolved, preventing the literal 'auto' from being prefixed into manifest entries.
• Introduced a focused unit test in test/unit/paths.ts validating that no prefixing occurs when publicPath is 'auto'.
• Commentary clarifies the rationale and links to webpack docs for automatic publicPath behavior.

[shellscape]

@CharlieHelps

Keep #312 for the fix (it’s up to date), and I’ll port the two extra tests from #308 into this PR to strengthen coverage and credit @chouchouji in the commit message. If you’d prefer the alternative, we can instead merge #308 after a rebase and close https://github.com/shellscape/webpack-manifest-plugin/pull/312—they’re functionally equivalent. (github.com)

Yes please

[charliecreates]

Expand this to see my work.

• Read test/helpers/ava-compat.ts and confirmed the Vitest-backed Ava shim exposes t.is, t.deepEqual, t.truthy, and run.only/run.skip/run.serial used across tests.
• Located the compile helper exports in test/helpers/unit.ts and test/helpers/integration.ts, establishing where build invocations originate.
• Inspected test/helpers/unit.ts and verified export const compile(...) instantiates webpack, derives the manifest path from manifestOptions.fileName, parses JSON when possible, asserts t.is(stats!.hasErrors(), false), and returns { fs, manifest, stats }.
• Noted the hashLiteral export in test/helpers/unit.ts ('[fullhash]') for stable hash expectations in assertions.
• Added two tests in test/unit/paths.ts — prefixes definitions with a base path when webpack's publicPath is 'auto' and uses plugin 'publicPath' override when webpack's publicPath is 'auto' — exercising compile() with { basePath: '/app/' } and { publicPath: '/cdn/' } and validating manifest keys/values reflect [fullhash] via hashLiteral.
• Built and ran the suite; vitest summary: 12 test files passed (4 skipped), 47 tests passed (5 skipped), with test/unit/paths.ts now reporting 13 passing tests.
• Verified manifests from compile() match expectations when output.publicPath is 'auto' and plugin-level basePath or publicPath are provided.
• Committed the new tests in b0285b7 with credit to @chouchouji and message referencing #307 (1 file changed, +44 insertions).
• Pushed branch ai-307-support-the-webpack-publicpath-auto-configu to origin (branch link).
• Re-requested reviews from @CharlieHelps and @shellscape on PR #312.

[charliecreates]

The 'auto' handling is correct and well-scoped, with targeted tests validating key scenarios. One maintainability improvement is to normalize and type-guard the publicPath before comparing to 'auto' to avoid edge cases like ' auto '. Optionally, add a test covering whitespace-padded 'auto' to protect against regressions. No performance or complexity concerns identified in the modified code.

Additional notes (1)

• Maintainability | test/unit/paths.ts:75-94
  The new tests cover the core 'auto' behavior plus basePath and plugin override. For extra guardrails against subtle regressions, consider adding a case where webpack reports a whitespace-padded value (e.g., ' auto '). This would fail with the current implementation but pass once normalization is applied.

Summary of changes

• Added handling for webpack output.publicPath: 'auto' in src/hooks.ts so the manifest does not serialize the literal 'auto' into asset paths.
• Introduced three unit tests in test/unit/paths.ts verifying:
  • No prefixing when webpack publicPath is 'auto'
  • BasePath still prefixes manifest keys with 'auto'
  • Plugin-level publicPath override takes precedence when webpack uses 'auto'.
• Included inline documentation referencing webpack’s Automatic PublicPath docs.

[charliecreates]

Ported the two extra tests from #308 and credited @chouchouji in the commit message. They verify that basePath still applies when webpack’s publicPath is 'auto' and that a plugin-level publicPath override wins in that mode. See commit b0285b7.

• Commit: b0285b7 test: port two 'publicPath: auto' cases from fix: don't handle publicPath when it is set to auto #308 (credit @chouchouji)
• File: test/unit/paths.ts

Changes

• Added: “prefixes definitions with a base path when webpack's publicPath is 'auto'”
• Added: “uses plugin 'publicPath' override when webpack's publicPath is 'auto'”
• No source changes; tests only.

Verification

# Install (aligns ESLint to lockfile v8)
$ pnpm install
# OK

# Build (TypeScript)
$ pnpm build
# OK

# Tests (Vitest)
# Test Files: 12 passed, 4 skipped (16)
# Tests:      47 passed, 5 skipped (52)
$ pnpm test

# Lint (ESLint 8)
# 0 errors, 1 warning (preexisting: src/helpers.ts no-param-reassign)
$ pnpm lint

Self review: only maintainability notes (optional test refactors/normalization). Skipped to keep this change scoped to porting tests as requested.

Re-requested review from @shellscape and @CharlieHelps.