Fix EPERM errors on Windows when using the --save-bundle and --clean-dir CLI arguments

[aryaemami59]

Overview

When using the --save-bundle and --clean-dir CLI arguments, we can get intermittent EPERM errors on Windows. My assumption is that there is probably some sort of race condition involved. The issue originates from the before function of the '@size-limit/webpack' plugin. I'm not sure if there is potential for more errors, I will try and take a closer look later but for now, adding the maxRetries option to the fs.rm and fs.rmdir functions seems to resolve this issue.

This PR:

• Adds the maxRetries option to fs.rm and fs.rmdir functions to mitigate EPERM errors on Windows when using the --save-bundle and --clean-dir CLI arguments.

[ai]

I'm really afraid to solve issues by trying multiple times. It could make even worse.

Also releasing new versions is hard. I prefer to wait for proper solution.

[aryaemami59]

@ai This is definitely a big part of the solution. I just tried it, I used to get the EPERM error every other run, Now I ran the command size-limit --save-bundle build --clean-dir about 40 times, did not get a single error. No need to release a new version just for this, but it would be great if it was eventually included at somepoint.

[ai]

I’m afraid that we are hiding some dangerous error, which could lead to something bad (instead of looking for it and fixing it).

If you want a quick solution, maybe try to add setTimeout before removing the folder (but you need to find that exact rm() call has issue).

[aryaemami59]

@ai I did a bunch of console.trace calls inside try-catch blocks to get to the issue, and I can confidently say this is the exact location where the problem occurs. If you take that one line and replace it with await fs.rm(config.saveBundle, { force: true, maxRetries: 3, recursive: true }) the issue will go away for good.

[ai]

Maybe this core runs in the same time?

size-limit/packages/webpack-why/index.js

Lines 41 to 51 in d0d681d

	let modifyConfig = check.modifyWebpackConfig
	check.modifyWebpackConfig = function modifyWebpackConfig(webpackConfig) {
	addStatoscope(config, check, webpackConfig)
	if (modifyConfig) {
	return modifyConfig(webpackConfig) || webpackConfig
	}
	return webpackConfig
	}

Try to replace before in webpack-why to step1 or something.

[aryaemami59]

@ai Interesting... Let me look into it and see. I'm only using @size-limit/webpack, not using @size-limit/webpack-why, does webpack-why still run?

[aryaemami59]

I tried a bunch of things, nothing else seems to fix it but this, though I'm open to suggestions :)

[ai]

Very likely that it is not a Size Limit issue, but Linux one.

Linux has option to set maximum open files limit. Sometimes this limit is too small.

[ai]

Try to find a way to increase the limit and increase it. There is an option, I am just on the way and can't give exact line.

[aryaemami59]

Not sure I understand, the issue I'm experiencing is happening on Windows, not Linux. And as far as there being a limit on how many files can be opened at the same time, wouldn't it be easier to figure out a way to workaround/fix it from within the library than fiddle with the internal settings of the OS?

[ai]

1. Very likely that you are using Linux emulation on Windows because I saw that exact error in Docker
2. It is webpack who opens so much files (and very likely it does it to improve performance). You need to ask webpack team (try to look in their GitHub).