Watch mode not working in Firefox since updating rspack to 1.1.0

[birtles]

After running pnpm start:firefox it starts downloading the dictionaries and then at some point rspack bails out with an error like the following:

pnpm start:chrome seems to work.

After running git bisect the culprit appears to be this changeset.

The closest issue I can find in rspack is web-infra-dev/rspack#8383

Not sure how to debug this yet but if we can't work it out soon, we might need to temporarily downgrade rspack to 1.0.x.

[enellis]

Just letting you know that I cannot reproduce this and and everything is working fine on my end (macOS 14.6, Node v20 and v23).

[birtles]

Thanks! I guess it might be a Windows issue then. I can reproduce it on two different computers but they're both Windows.

[birtles]

I really need to fix this before the next release since it's making it really hard to test anything at the moment. So far I've determined that dropping clean: true from rspack.config.js fixes the initial problem (but I really do want to clean when building, at least when not in watch mode).

I'm not sure if it's related but I'm seeing constant reloads in Chrome too.

If I can build rspack from source I can try bisecting the rspack changeset that causes it and possibly add some logging too.

[birtles]

Dug into this a bit more today. I've been trying to build and bisect locally but I'm having a hard time getting yalc to publish the necessary binding files so that pnpm picks them up. I'm not quite sure it's even possible.

A couple of things I have worked out however:

1. Version 1.2.0-beta.0 of rspack does not fix the issue. It makes it worse (i.e. fails more quickly).
2. The issue does not reproduce in 1.1.0-beta.0 meaning the regression is in this range.

[birtles]

I notice that rspack is using pkg.pr.new but trying to use the packages from web-infra-dev/rspack#8325 (comment) (where the pkg.pr.new setup was restored) gives me

ERR_PNPM_FETCH_404  GET https://pkg.pr.new/@rspack/cli@8325: Not Found - 404

[hardfist]

Thanks! I guess it might be a Windows issue then. I can reproduce it on two different computers but they're both Windows

I actually met same problem in our windows CI and the cause maybe related to docker or antivirus apps which may add fs lock to generated file(which is actually very normal)
I fix it by doing fs retry in ci https://github.com/web-infra-dev/rspack/pull/7803/files#diff-34a48fc8f5c08955a23170a0593fc01c09618bd011daeb7707a731409db27d65

[hardfist]

I notice that rspack is using pkg.pr.new but trying to use the packages from web-infra-dev/rspack#8325 (comment) (where the pkg.pr.new setup was restored) gives me

ERR_PNPM_FETCH_404  GET pkg.pr.new/@rspack/cli@8325: Not Found - 404

sorry we temporarily take pkg.pr.new down because the recent attack on rspack, we will fix it when we make sure we fix all potential attack security about issue comment triggered action.

[birtles]

I tried this approach:

If I want to debug in my local machine, I often run node local_build/bin/rspack -c project_i_want_to_test/rspack.config.js, so I can even use debugger to debug
If I want to debug in CI or other complex environment, I often build a canary version for debugging.

But I just get:

$ node packages/rspack-cli/bin/rspack.js -c ~/10ten-ja-reader/rspack.config.js -w
Error [ERR_REQUIRE_ESM]: require() of ES Module C:\Users\Brian\10ten-ja-reader\rspack.config.js from C:\Users\Brian\rspack\packages\rspack-cli\dist\index.js not supported.
Instead change the require of rspack.config.js in C:\Users\Brian\rspack\packages\rspack-cli\dist\index.js to a dynamic import() which is available in all CommonJS modules.
    at crossImport (C:\Users\Brian\rspack\packages\rspack-cli\dist\index.js:23:26)
    at loadRspackConfig (C:\Users\Brian\rspack\packages\rspack-cli\dist\index.js:698:49)
    at RspackCLI.loadConfig (C:\Users\Brian\rspack\packages\rspack-cli\dist\index.js:842:34)
    at RspackCLI.createCompiler (C:\Users\Brian\rspack\packages\rspack-cli\dist\index.js:726:33)
    at Object.handler (C:\Users\Brian\rspack\packages\rspack-cli\dist\index.js:463:40) {
  code: 'ERR_REQUIRE_ESM'
}

I guess it might work with Node 23 but I'm currently on Node 20.

Thanks! I guess it might be a Windows issue then. I can reproduce it on two different computers but they're both Windows

I actually met same problem in our windows CI and the cause maybe related to docker or antivirus apps which may add fs lock to generated file(which is actually very normal) I fix it by doing fs retry in ci https://github.com/web-infra-dev/rspack/pull/7803/files#diff-34a48fc8f5c08955a23170a0593fc01c09618bd011daeb7707a731409db27d65

Ah, interesting. I think the issue in this case might be because our rspack.config.js defines multiple configurations and also sets clean: true so I suspect it's trying to delete files while another configuration is generating files in the same directory. Perhaps the change to use the async thread pool made this more likely?

I'd still like to get a local build to run because rspack seems to be rebuilding more frequently than I'd expect and I'd like to debug why in case I have it misconfigured.

[birtles]

I guess it might work with Node 23 but I'm currently on Node 20.

Looks like it works with Node 23!

[birtles]

Looks like it works with Node 23!

Unfortunately I haven't been able to reproduce the problem in Node 23 yet. In Node 22 it seems to reproduce less frequently but I also got a slightly different error when it did reproduce:

[rspack-cli] [Error:   × Rspack FS Error: Error: EBUSY: resource busy or locked, unlink 'C:\Users\Brian\10ten-ja-reader\dist-firefox\data\words.ljson'
  │
  ╰─▶ Error: EBUSY: resource busy or locked, unlink 'C:\Users\Brian\10ten-ja-reader\dist-firefox\data\words.ljson'

] {
  code: 'GenericFailure'
}
[firefox-profile] cannot delete profileDir on exit C:\Users\Brian\AppData\Local\Temp\firefox-profileTUpVgi/ Error: EBUSY: resource busy or locked, unlink 'C:\Users\Brian\AppData\Local\Temp\firefox-profileTUpVgi\bounce-tracking-protection.sqlite'
    at unlinkSync (node:fs:1953:11)
    at _unlinkSync (node:internal/fs/rimraf:215:14)
    at rimrafSync (node:internal/fs/rimraf:196:7)
    at node:internal/fs/rimraf:254:9
    at Array.forEach (<anonymous>)
    at _rmdirSync (node:internal/fs/rimraf:251:7)
    at rimrafSync (node:internal/fs/rimraf:194:7)
    at Object.rmSync (node:fs:1248:10)
    at FirefoxProfile._cleanOnExit (C:\Users\Brian\10ten-ja-reader\node_modules\.pnpm\[email protected]\node_modules\firefox-profile\lib\firefox_profile.js:289:12)
    at process.FirefoxProfile.onExit (C:\Users\Brian\10ten-ja-reader\node_modules\.pnpm\[email protected]\node_modules\firefox-profile\lib\firefox_profile.js:172:12) {
  errno: -4082,
  code: 'EBUSY',
  syscall: 'unlink',
  path: 'C:\\Users\\Brian\\AppData\\Local\\Temp\\firefox-profileTUpVgi\\bounce-tracking-protection.sqlite'
}

[birtles]

I think if I switch to Node 22 and re-install all the dependencies it doesn't break?

For now, switching to Node 22 seems like a useful step anyway.

[hardfist]

I tried this approach:

If I want to debug in my local machine, I often run node local_build/bin/rspack -c project_i_want_to_test/rspack.config.js, so I can even use debugger to debug
If I want to debug in CI or other complex environment, I often build a canary version for debugging.

But I just get:

$ node packages/rspack-cli/bin/rspack.js -c ~/10ten-ja-reader/rspack.config.js -w
Error [ERR_REQUIRE_ESM]: require() of ES Module C:\Users\Brian\10ten-ja-reader\rspack.config.js from C:\Users\Brian\rspack\packages\rspack-cli\dist\index.js not supported.
Instead change the require of rspack.config.js in C:\Users\Brian\rspack\packages\rspack-cli\dist\index.js to a dynamic import() which is available in all CommonJS modules.
    at crossImport (C:\Users\Brian\rspack\packages\rspack-cli\dist\index.js:23:26)
    at loadRspackConfig (C:\Users\Brian\rspack\packages\rspack-cli\dist\index.js:698:49)
    at RspackCLI.loadConfig (C:\Users\Brian\rspack\packages\rspack-cli\dist\index.js:842:34)
    at RspackCLI.createCompiler (C:\Users\Brian\rspack\packages\rspack-cli\dist\index.js:726:33)
    at Object.handler (C:\Users\Brian\rspack\packages\rspack-cli\dist\index.js:463:40) {
  code: 'ERR_REQUIRE_ESM'
}

try run this command in your repo other than in rspack repo(it's actually a tricky bug in dealing with esm config, which i will fix soon)

node rspack/packages/rspack-cli/bin/rspack.js -c rspack.config.js

[birtles]

try run this command in your repo other than in rspack repo(it's actually a tricky bug in dealing with esm config, which i will fix soon)

Thank you so much! That worked and I was finally able to bisect the regression. It turns out it comes from changeset 1161016 (fix: use incremental in production build).

[hardfist]

Thank you so much! That worked and I was finally able to bisect the regression. It turns out it comes from changeset 1161016 (fix: use incremental in production build).

en, that's weird, @ahabhgk any idea?

[ahabhgk]

Could you try set experiments.incremental = { make: true, emitAssets: true } to see whether this error still exists?

[birtles]

Could you try set experiments.incremental = { make: true, emitAssets: true } to see whether this error still exists?

Thanks @ahabhgk! I tried the following:

rspack version	Node version	Config	Result
Changeset 7f96765 (debug build)	20.11.0	(default experiments.incremental)	🟢 OK
Changeset 1161016 (debug build)	20.11.0	(default experiments.incremental)	❌ Abort
v1.1.8	20.11.0	(default experiments.incremental)	❌ Abort
v1.1.8	22.13.0	(default experiments.incremental)	🟢 OK
v1.1.8	20.11.0	experiments: { incremental: false }	❌ Abort
v1.1.8	20.11.0	experiments: { incremental: { make: true, emitAssets: true } }	❌ Abort
v1.1.8	20.11.0	Default experiments.incremental but without output: { clean: true }	🟢 OK

So it looks like some sort of bad interaction between Changeset 1161016 and Node < 22 and output: { clean: true }. Note also that this is on Windows.

(I also tried removing the multiple compile targets (i.e. exporting only a single object from rspack.config.js instead of an array) but the problem still persists.)

[birtles]

For now I've switched CI to Node 22 in #2191.