ai / size-limit

Calculate the real cost to run your JS app or lib to keep good performance. Show error in pull request if the cost exceeds the limit.
MIT License
6.48k stars 1.82k forks source link

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

Open aryaemami59 opened 1 month ago

aryaemami59 commented 1 month ago

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:

ai commented 1 month ago

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 commented 1 month ago

@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 commented 1 month ago

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 commented 1 month ago

@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 commented 1 month ago

Maybe this core runs in the same time?

https://github.com/ai/size-limit/blob/d0d681d7d0c686773650ba1af03d892f0081e761/packages/webpack-why/index.js#L41-L51

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

aryaemami59 commented 1 month ago

@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 commented 1 month ago

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

ai commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago
  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).