Lage hasher crashes trying to run git hash-object on a symlink

[kensternberg-authentik]

Describe the bug

Lage getHashForFiles() function throws an exception when attempting to get the hash of a symlink

To Reproduce

Steps to reproduce the behavior:

1. Start with a monolith;
2. Move the entire monolith into a subfolder, such as packages/monolith.
3. Using the tutorial as a guide, create a new package.json and lage.config.js in the project root.
4. Run npm install. (Consequence: a new symlink is created from ./node_modules/@organization/monolith -> ../packages/monolith)
5. Run lage build.
6. See error. (Note that this is a hacked copy of Lage: I reduced the call to git hash-object to run on individual files, so I could figure out where this was failing.)

Error: Command failed with exit code 128: git hash-object /Users/ken/projects/dev/web/node_modules/@goauthentik/mono

This is as expected, as git hash-object on a symlink is nonsensical:

$ git hash-object node_modules/@goauthentik/mono
fatal: Unable to hash web/node_modules/@goauthentik/mono
$ ls -l node_modules/\@goauthentik/mono
lrwxr-xr-x  1 ken  staff  18 Dec 20 13:38 node_modules/@goauthentik/mono@ -> ../../packages/mono

Expected behavior

I expected lage to not attempt to hash symlinks. I'm not sure what alternative you have for tracking them, but git hash-object cannot be used in this case. It's not a file, and it refers to a folder, which is also not hashable.

Workaround

Adding 'node_modules/@goauthentik/mono' to .gitignore worked, but that's not a very viable long-term solution.

Environment/Troubleshooting

Please paste in the result of npx envinfo to help identify your run time environment.

 System:
    OS: macOS 13.3
    CPU: (12) arm64 Apple M2 Max
    Memory: 110.56 MB / 32.00 GB
    Shell: 3.2.57 - /bin/bash
  Binaries:
    Node: 18.18.0 - ~/.nvm/versions/node/v18.18.0/bin/node
    Yarn: 1.22.19 - ~/.nvm/versions/node/v18.18.0/bin/yarn
    npm: 9.8.1 - ~/.nvm/versions/node/v18.18.0/bin/npm
  Managers:
    Cargo: 1.71.0 - ~/.cargo/bin/cargo
    Homebrew: 4.2.0 - /opt/homebrew/bin/brew
    pip3: 23.1.2 - ~/Library/Caches/pypoetry/virtualenvs/authentik-BoGTmjdo-py3.12/bin/pip3
    RubyGems: 3.0.3.1 - /usr/bin/gem
  Utilities:
    Make: 3.81 - /usr/bin/make
    GCC: 14.0.3 - /usr/bin/gcc
    Git: 2.39.2 - /usr/bin/git
    Clang: 14.0.3 - /usr/bin/clang
    FFmpeg: 6.0 - /opt/homebrew/bin/ffmpeg
    Curl: 7.87.0 - /usr/bin/curl
  Virtualization:
    Docker: 23.0.5 - /usr/local/bin/docker
  IDEs:
    Emacs: 29.1 - /opt/homebrew/bin/emacs
    Vim: 9.0 - /usr/bin/vim
    Xcode: /undefined - /usr/bin/xcodebuild
  Languages:
    Bash: 3.2.57 - /bin/bash
    Go: 1.20.4 - /usr/local/go/bin/go
    Perl: 5.30.3 - /usr/bin/perl
    Python: 3.12.0 - /Users/ken/Library/Caches/pypoetry/virtualenvs/authentik-BoGTmjdo-py3.12/bin/python
    Python3: 3.12.0 - /Users/ken/Library/Caches/pypoetry/virtualenvs/authentik-BoGTmjdo-py3.12/bin/python3
    Ruby: 2.6.10 - /usr/bin/ruby
    Rust: 1.71.0 - /Users/ken/.cargo/bin/rustc
  Databases:
    PostgreSQL: 14.9 - /opt/homebrew/bin/postgres
    SQLite: 3.39.5 - /usr/bin/sqlite3
  Browsers:
    Chrome: 120.0.6099.129
    Safari: 16.4
  Monorepos:
    Yarn Workspaces: 1.22.19

[ecraig12345]

This might be fixed by the latest glob-hasher version (lage dependency). It's not obvious from the description, but I remember this change was fixing some related issues.