Audit can't detect lockfile in workspace root

[gabidobo]

@gabidobo FYI, still not working here. I've tried running from both the root with -p and from an app package subdirectory itself and it still doesn't seem to be finding the yarn.lock in the repo root:

monorepo on  develop [$⇡]
❯ sandworm-audit -p packages/apps/an-app
Sandworm 🪱
Security and License Compliance Audit
⠋ Building dependency graph...
❌ Failed: No lockfile found

monorepo on  develop [$⇡]
❯ cd packages/apps/an-app

packages/apps/an-app on  develop [$⇡]
❯ sandworm-audit
Sandworm 🪱
Security and License Compliance Audit
⠋ Building dependency graph...
❌ Failed: No lockfile found

packages/apps/an-app on  develop [$⇡]
❯ sandworm-audit -v
1.46.0

Originally posted by @liamjones in https://github.com/sandworm-hq/sandworm-audit/discussions/101#discussioncomment-6853880

[gabidobo]

@liamjones thank you for reporting this! Looks like Audit is having trouble detecting your workspace root.

Just to make sure: your package.json manifest at the root of your workspace includes a workspaces key that holds an array of globs/paths to the workspace projects, correct?

[liamjones]

Yup, root package.json:

{
  "private": true,
  "workspaces": {
    "packages": [
      "packages/*/*"
    ]
  }
}

(plus keys for scripts, dependencies, engines, etc)

[gabidobo]

Thanks for the quick reply!

The issue seems to be that we expect workspaces to be an array, while in your case it's an object.

Is this a Yarn feature, or are you using a separate build system? I can only find references to package managers expecting an array there.

[liamjones]

Oh, interesting, let me see if I can work out if it's always been like that. We're using yarn 1 in combination with lerna. It may just be wrong but apparently yarn has been coping with it - I can do yarn workspace a-package-name command and that works...

[liamjones]

Okay, I've dug through git history and understand now. This is apparently supported in yarn but not documented directly on the workspaces page, only through the 'nohoist' link on that page to the yarn blog?! https://classic.yarnpkg.com/blog/2018/02/15/nohoist/#how-to-use-it

When I originally did the setup I needed to nohoist something hence why that structure exists. I later fixed the issue so we could drop nohoist but I didn't move packages back up to be a plain array - it seems yarn is still happy with that structure even without a nohoist key. In fact, it seems internally it's always normalised to an object with a packages key: https://github.com/yarnpkg/yarn/blob/158d96dce95313d9a00218302631cd263877d164/src/config.js#L984

[gabidobo]

Very interesting, thank you so much for digging that up! 🙏

I'll update our code to also support this format, and let you know when a new version is available.

[gabidobo]

Ok, v1.48.2 is published 👍 should also support the object format.

[liamjones]

Thanks @gabidobo, all working now 👍