4

Switching to the yarn zero installs approach (see https://yarnpkg.com/features/zero-installs) I encountered errors in the following style when running our CI pipeline:

/app/.pnp.cjs:47262
throw firstError;
      ^
 
Error: Required unplugged package missing from disk. This may happen when switching branches without running installs (unplugged packages must be fully materialized on disk to work).
 
Missing package: nodemon@npm:2.0.7
Expected package location: /app/.yarn/unplugged/nodemon-npm-2.0.7-7b95e46511/node_modules/nodemon/
.
.
.

Ok, that was expected, since this approach doesn't run yarn install and just uses the files from the cache in .yarn. Following the advice in the last point of this paragraph https://yarnpkg.com/features/zero-installs#how-do-you-reach-this-zero-install-state-youre-advocating-for I adjusted my .gitignore and .dockerignore files to include this:

.yarn/*
!.yarn/cache
!.yarn/patches
!.yarn/plugins
!.yarn/releases
!.yarn/sdks
!.yarn/versions
!.yarn/unplugged

The unplugged folder should therefore be able to be committed to the repo and with that, available during the CI pipeline. But as you can see, the files of each package in the unplugged folder remain greyed out and cannot be committed.

The output of git status --ignore still lists the unplugged dir, even after checking all .gitignore files:

.yarn/.DS_Store
.yarn/build-state.yml
.yarn/cache/.gitignore
.yarn/install-state.gz
.yarn/unplugged/

What can I do to get the files into the repo or otherwise avoid the error mentioned in the beginning?

yarn folder

GoWithTheFlow
  • 252
  • 6
  • 16
  • 1
    `git status` does not have a(n) `--ignore` option; did you mean `--ignored`? (This takes an additional optional argument, `=tradiational`, `=matching`, `=no`.) – torek Jan 19 '22 at 19:05
  • In any case, if `git status` without `--ignored`, or with `--ignored=traditional`, lists `.yarn/unplugged/` as holding *untracked* files, that would mean there are files in there that are currently untracked but will *not* be skipped-over by an en-masse `git add .` or similar. That would imply you're just one `git add` away from where you want to be. – torek Jan 19 '22 at 19:07
  • 1
    Use `git check-ignore -v` with various file names to find out what `.gitignore`-or-equivalent file is causing Git to *not* add a file with an en-masse `git add .`. That is, if `git add .` is not adding `.yarn/unplugged/foo`, run `git check-ignore -v .yarn/unplugged/foo` to see why not. – torek Jan 19 '22 at 19:11
  • @torek Thank you, good idea on checking the subdirs! I only tried `git check-ignore -v .yarn/unplugged` which pointed me to the line in my `.gitignore` saying `!.yarn/unplugged`. But using your suggestion I was pointed to this line `**/node_modules/` which somehow fits the files in the `unplugged` dir. I added `!.yarn/unplugged/**/node_modules` to the `.gitignore` and now was able to commit them without using `git add -f`. If you want to add it as an answer I'll accept it. Thank you again! – GoWithTheFlow Jan 20 '22 at 01:47
  • Yes, the way the ignore rules work in Git gets seriously complicated sometimes. :-) – torek Jan 20 '22 at 05:21

1 Answers1

4

As per comments, it turns out that another ignore rule was overriding the desired un-ignore rule. The key diagnostic was to use:

git check-ignore -v .yarn/unplugged/somedir/node_modules/somefile

(or similar), which pointed to the **/node_modules/ line that caused somefile within this node_modules/ within .yarn/unplugged/ to be skipped.

The more general takeaway here is that if git add . is skipping some file(s), you can use often use git check-ignore -v to find out why. Note that it's important to use it on a particular skipped file. (It also doesn't do very much good with submodules, but that's another problem entirely.)

torek
  • 448,244
  • 59
  • 642
  • 775