`fsevents` causing Yarn `0028` error deploying to Netlify and "The lockfile would have been modified"

Get Help and Help Others
1

repo: tmt-redwood-js

I largely followed this guide but builds are consistently failing:

4:54:55 PM: Failed during stage 'Install dependencies': dependency_installation script returned non-zero exit code: 1
4:54:55 PM: ➤ YN0085: │ + fsevents@patch:fsevents@npm%3A2.3.3#optional!builtin<compat/fsevents>::version=2.3.3&hash=df0bf1, and 4 more.
4:54:55 PM: ➤ YN0085: │ - fsevents@patch:fsevents@npm%3A1.2.13#~builtin<compat/fsevents>::version=1.2.13&hash=d11327, and 4 more.
4:54:55 PM: ➤ YN0000: └ Completed in 28s 794ms
4:54:55 PM: ➤ YN0000: ┌ Post-resolution validation
4:54:55 PM: ➤ YN0028: │ The lockfile would have been modified by this install, which is explicitly forbidden.

I’ve tried adding fsevents as an explicit dependency, both @2.3.3 and @1.2.13. I’ve also tried setting the ENABLE_EXPERIMENTAL_COREPACK environment variable to 1 as suggested by this thread on RedwoodJS + Vercel (which I know is different than Netlify but the underlying error seemed similar.) Nothing has worked.

ETA: e.g. pinning fsevents@1.2.13 results in

5:17:42 PM: Failed during stage 'Install dependencies': dependency_installation script returned non-zero exit code: 1
5:17:42 PM: ➤ YN0085: │ + fsevents@patch:fsevents@npm%3A1.2.13#optional!builtin<compat/fsevents>::version=1.2.13&hash=d11327, and 4 more.
5:17:42 PM: ➤ YN0085: │ - fsevents@patch:fsevents@npm%3A1.2.13#~builtin<compat/fsevents>::version=1.2.13&hash=d11327, and 4 more.

Any suggestions would be very appreciated.

ETA: I spent some time running different builds and trying to modify my yarn.lock file to be in line with what the build is expecting. The end result is this:

1:25:17 PM: Installing npm packages using Yarn version 4.1.1
1:25:18 PM: ➤ YN0000: · Yarn 4.1.1
1:25:18 PM: ➤ YN0000: ┌ Resolution step
1:25:42 PM: Failed during stage 'Install dependencies': dependency_installation script returned non-zero exit code: 1
1:25:42 PM: ➤ YN0000: └ Completed in 24s 480ms
1:25:42 PM: ➤ YN0000: ┌ Post-resolution validation
1:25:42 PM: ➤ YN0028: │ The lockfile would have been modified by this install, which is explicitly forbidden.
1:25:42 PM: ➤ YN0000: └ Completed
1:25:42 PM: ➤ YN0000: · Failed with errors in 24s 574ms
1:25:42 PM: Error during Yarn install

I’m really at my wits’ end, here. Any suggestions at all would be really appreciated.

2

I “solved” this by setting YARN_FLAGS=--no-immutable in Netlify. I don’t like it, but at least builds are building for now.

3

@swizzard The error you’re seeing means that your yarn.lock file needs to be updated and committed to your git repo. This is necessary after you make changes to package.json dependencies.

:warning: You should not need to set that Env Var as it will end up getting you in trouble in the long run.

Do this locally:

  • run yarn or yarn install (same thing)
  • there should be changes to the file yarn.lock
  • commit those changes to git and then push to your repo
  • when you redeploy, you should see a clean build log (reminder to remove the env var)

Please let me know if this doesn’t work for you.

4

Believe me I tried that, a dozen times. I assume the issue is between my local build env and whatever Netlify is using. I briefly considered seeing if I could find a matching docker image just for yarn lockfile nonsense, then gave up and went with the env var.

If this were more than a hobby project it’d be a dealbreaker; as it stands I can risk some occasional dependency issues.

5

Well then, I’m now scratching my head along with you. I’ve never encountered this situation before.

Understand your usage of the Env Var override. Sound like what I would have done given your situation!

We’ll keep a lookout if more examples of this pop up. Please do the same. :pray:

6

Try setting the Netlify variable YARN_ENABLE_IMMUTABLE_INSTALLS = false. Do this one time to let netlify update your packages to match your apps lock file. Then you can remove it or set it to true to prevent future unintended updates to your packages.

2 Likes
7

This sounds promising! I’ll give it a shot next week.

8

@raj I just tried this and while YARN_ENABLE_IMMUTABLE_INSTALLS=false works, the effect doesn’t seem to persist–I set YARN_ENABLE_IMMUTABLE_INSTALLS=true and tried to manually redeploy and the build failed in the resolution step with the same error.