Snyk CLI appears to still check package.json dependencies/devDependencies even when provided with a yarn.lock

[shimmerjs]

• node -v: 10 LTS
• snyk -v: 1.122.0
• Command run: snyk test

Expected behaviour

I would expect that the detection of my yarn.lock file in my yarn workspaces monorepo would parse all of my modules automatically, even if I have no dependencies in the top-level package.json.

Actual behaviour

When running snyk test in a repository with a yarn.lock but no dependencies in package.json, it says that it has tested 0 modules. If I run snyk test --dev, I now see all modules scanned, both dependencies and devDependencies, for entire monorepo (because all are in root yarn.lock). My guess would be that the CLI does not read the yarn.lock file unless it sees that package.dependencies is a thing.

---

If applicable, please append the --debug flag on your command and include the output here **ensuring to remove any sensitive/personal details or tokens.

[feedm3]

I'm running into the same problem. Also having a large monorepo with yarn with all dependencies listed in the root yarn.lock file.

When I run the monitor command all I see in the snyk dashboard is the package.json (with 0 dependencies). No yarn.lock.

snyk monitor --org=test-org --file=yarn.lock --project-name=test-org-yarn --debug

Also, maybe this is error is related: I cannot run yarn wizard as it hangs during the dependency scan.

Snyk debug output:

  snyk monitor { _: [ [Circular] ],
  org: 'test-org',
  file: 'yarn.lock',
  'project-name': 'test-org-yarn',
  debug: true } +0ms
  snyk analytics add packageManager yarn +0ms
  snyk sending request to: https://snyk.io/api/v1/monitor/npm +0ms
  snyk request body size: 495 +0ms
  snyk gzipped request body size: 315 +0ms
  snyk analytics add payloadSize 495 +6ms
  snyk analytics add gzippedPayloadSize 315 +0ms
  snyk not using proxy +1ms

Monitoring /Users/test/IdeaProjects/test/test-org...

A yarn.lock file was detected - continuing as a Yarn project.
Explore this snapshot at https://app.snyk.io/org/{...}

Notifications about newly disclosed issues related to these dependencies will be emailed to you.

  snyk analytics { args: 
   [ { org: 'test-org',
       file: 'yarn.lock',
       'project-name': 'test-org-yarn',
       debug: true } ],
  command: 'monitor',
  metadata: 
   { packageManager: 'yarn',
     payloadSize: 495,
     gzippedPayloadSize: 315 },
  version: '1.124.0',
  os: 'macOS',
  nodeVersion: 'v8.11.4',
  id: '0fd3fb6b969141c52ac1439655ac91b7416b3e72',
  ci: false,
  durationMs: 1535 } +1s
  snyk sending request to: https://snyk.io/api/v1/analytics/cli +1s
  snyk request body size: 329 +0ms
  snyk gzipped request body size: 251 +0ms
  snyk not using proxy +1ms

[denissnykio]

Hi, My name is Denis BEN OLIEL, and I'm Snyk Customer Success Manager I checked both cases with our R&D and Product Manager To start scanning your apps, finding & fixing vulnerabilities, we recommend to run 'snyk test --dev' In parallel, snyk is working to improve the support of yarn workspaces Feel free to write to [email protected] if you have any additional question or issue Best Regards, Denis

[feedm3]

Hi Denis,

thanks a lot, with --dev it's working 👍

edit: it turns out that it is only checking the dev dependencies :/

[b-smets]

Same problem for me when running snyk monitor --file=yarn.lock. The yarn.lock file seems to be ignored and only the dependencies in the toplevel package.json file are submitted. Adding --dev will only include the dev dependencies of the toplevel package.json.

I would expect all dependencies in the yarn.lock file to be submitted for the project.

Note that I was able to successfully run snyk wizard which detected the yarn.lock file successfully and ran the analysis on all the dependencies inside. I now have a .snyk policy file containing policies for all vulnerable dependencies, including these in subprojects. The problem seems to be related to the behaviour of snyk monitor and snyk test.

[denissnykio]

Hi, Are yarn.lock and package.json in the directory where you run snyk monitor ? Can you please send me both files on Monday, so I can investigate with R&D Have a good week-end, Denis Snyk CSM for Audi

[denissnykio]

Hi Bart, There may be a temporary workaround to handle both package.json and yarn.lock, until we support yarn workspace (in the near roadmap):

1. copy yarn.lock in each directory that contains a package.json file
2. run 'snyk monitor' in each directory that contains a package.json file Would it be an acceptable workaround ? Note that we must first develop a flag that allows the CLI to ignore 'out of sync' issue Denis

[lili2311]

hi all!

Just an update that we are looking at supporting yarn workspaces, the team is planning a spike on this in the coming weeks. So stay tuned! In the team time I would love to have some input, would scanning the project be best for you as:

• scanning just the root lockfile to get a full list of all vulnerabilities across all workspaces. (This may mean we can't easily link fixes to the right package.json files but does provide one big list)
• scanning each workspace for vulnerabilities separately. We are leaning towards this one heavily, but keen to know what might be valuable.

[lili2311]

A new update! We have spiked this and have a working prototype, will be scheduling the work into a future sprint and plan to release this soon 💃

A possible workaround for now, is to copy over the yarn.lock into each module. It is not great but will allow us to test directly against the lockfile in each case. Hope this is useful

[feedm3]

Sorry for the late reply. Happy to hear that there is progress happening 👍

Just to point out what I expect from the implementation: When using snyk with yarn workspaces, I want to run one command (snyk test or/and snyk monitor) in the root folder of the project to get all vulnerabilities (including license problems). I'm not sure whether scanning the root yarn.lock or every workspace separately is better, I just want to know if there are any issues in the whole project.

Optional goals:

• Information if the issue occurs in dependencies or devDependencies.
• Ignore certain workspaces or modules. This would be helpful as our monorepo also contains packages that are internal developer tools and we would like to check them separately (the CI pipeline doesn't need to fail just because there is an issue with that tools).

@lili2311 can you tell me when the workspace feature will available?

[lili2311]

👋 Hi, unfortunately I don't have an exact date available apart from this quarter. We are about to start a new quarter but are already working on the system changes needed to support yarn workspaces. Once the hard work is done changing our shape of the system to understand a projects like yarn workspace we can make the spike we have come to life & release it.

As preparation for this we have now released Yarn as it's own project type, try it out! It is available for any new project that gets monitored or imported with yarn.lock present.

Until recently npm & yarn were treated in the same bucket so this is long awaited improvement in the right direction.

[marcelkottmann]

Hi @lili2311 , can you give us an update about the progress? Is it possible to communicate a rough date, otherwise we have to implement a workaround, which we want to avoid?

[marcelkottmann]

@lili2311 Is there any progress here?

[ebickle]

This issue bit us pretty hard as a surprise - Snyk was reporting minimal #s of dependencies and no issues when in reality teams had a lot more packages that weren't being monitored.

At minimum a patch should be put in place for the CLI and Web interfaces to warn about this instead of silently "failing" and letting people think they're okay when they aren't. Non-zero return codes and all that.

[karthikiyengar]

Hi Bart, There may be a temporary workaround to handle both package.json and yarn.lock, until we support yarn workspace (in the near roadmap):

1. copy yarn.lock in each directory that contains a package.json file

2. run 'snyk monitor' in each directory that contains a package.json file
   Would it be an acceptable workaround ?
   Note that we must first develop a flag that allows the CLI to ignore 'out of sync' issue
   Denis

I hope support for workspaces is still prioritized and on the cards. We desperately need this. Right now, I've implemented the workaround, but it looks like we still need that flag for vulnerabilities to be displayed correctly. Any progress on this?

[lili2311]

👋 Hi all, to keep you updated we are currently doing some internal work that will allow yarn workspaces to be then prioritised into sprint work there is some system wide changes that are needed to support this new type of project that has a lockfile referenced from multiple package.json files.

We have successful spike but it relied on the above work to be in place to be releasable. No specific dates as of yet.

[lili2311]

👋 Hi folks, I have some good news. We have a PR up for some initial support for snyk test and snyk monitor. Will update once this is released 🎉

[lili2311]

👋 This has now been released, please try it out by grabbing CLI version 1.352.1 or higher. It works similar to --all-projects so you need to specify the scan depth depending on your projects setup.

snyk test --yarn-workspaces --detection-depth=4 for example.

[lili2311]

@marcelkottmann @karthikiyengar @ebickle please let me know if this covers your use-cases on CLI?

[marcelkottmann]

Hi @lili2311 , I tested the given command with the latest snyk (version 1.359.1), but unfortunately it leads to an error in our (lerna 3 managed) monorepo. The error message is

Dependency @AAA/BBB was not found in yarn.lock. Your package.json and yarn.lock are probably out of sync. Please run "yarn install" and try again.

This dependency @AAA/BBB is a package inside the lerna managed monorepo. Another package of this monorepo references this. It is not an external dependency and is not part of yarn.lock.

[lili2311]

hi @marcelkottmann we focused on Yarn workspaces rather than Lerna support at this moment, if you are able to share what is your expectation here and if you have an example to test with that would be very helpful!

For now you can skip this by passing in --strict-out-of-sync=false after the command. We check if a dependency referenced in the manifest is present in the lock since this is how we look up resolution & yarn would normally expect this too, if we if we can't find it we throw this by default but it can be skipped. If you could share steps/example repo to reproduce this with we can look at supporting this behaviour without the need to skip out of sync check.

[ebickle]

@lili2311 the new feature failed for me, unfortunately. Running on a complex project from a different team in the company I received the following error: Dependency @private-repo/private-package was not found in yarn.lock. Your package.json and yarn.lock are probably out of sync. Please run "yarn install" and try again`.

The project has the following structure:

• An .npmrc file exists and defines @private-repo as a registry pointing to a private NPM registry at https://npm.pkg.github.com.
• The package.json file defines the dependency "@private-repo/private-package": "*"

Note the wildcard used for the package version for the library stored in the private internal NPM repository. Yarn does not place wildcard "*" dependencies inside of yarn.lock, causing the basic case of snyk test without any arguments to fail. See https://github.com/yarnpkg/yarn/issues/6415 , https://github.com/yarnpkg/yarn/issues/6695 and https://github.com/yarnpkg/yarn/issues/3951#issuecomment-316424639

[lili2311]

@ebickle thanks for this explanation. We can look into improving this behaviour for workspaces if the dep doesn't end up being referenced in a lockfile as we expect. For now you can skip this as described above, this dependency will show up in UI as unresolved. What is your expected behaviour from Snyk in this case?

[ebickle]

@lili2311 Gave it another try.

snyk test --strict-out-of-sync=false --yarn-workspaces --detection-depth=4 worked. I was able to successfully scan the complex project, but I did note that the default CLI output was so verbose it overflowed my terminal line buffer. I received some warnings about "Tip: Detected multiple supported manifests (51), use --all-projects to scan all of them at once.". The message seemed strange considering I was already using --yarn-workspaces to scan them.

snyk monitor failed. It appeared to end up in some sort of rapid recursive loop flashing text similar to "Posting monitor snapshot for yarn.lock ..." on the CLI. I couldn't quite catch what the other message it alternated with was. Looks like there's some sort of infinite loop bug lurking in the code somewhere. When I checked the website interface, I could see a single top level project showing in the interface, but no child projects.

Also, within the Snyk website UI I'm shown the message "Your manifest and lock file are out of sync" - likely due to the --strict-out-of-sync=false. Should I file a separate Snyk issue for this? They aren't out of sync, it's just how Yarn works with certain dependencies :)

[lili2311]

"Tip: Detected multiple supported manifests (51), use --all-projects to scan all of them at once.". The message seemed strange considering I was already using --yarn-workspaces to scan them.

@ebickle Ah yes thanks, probably makes sense to skip the tip for yarn workspaces scans.

For the monitor issues it would be good to raise a support case so we can debug this and fix, there should not be an issue monitoring all 51 projects. Please could you email [email protected] with an example project or actual project to reproduce the issue and the captured debug output of snyk monitor --strict-out-of-sync=false --yarn-workspaces --detection-depth=4 -d or post here is this is not sensitive. We can check the logs to see what the failure reason was for this and see how we can help.

[lili2311]

Ah yes thanks, probably makes sense to skip the tip for yarn workspaces scans.

This has been fixed & released

We are discussing internally how to handle the local packages in a workspace for a smoother exprecience.

[phad]

Hi Lili, is there any update on handling repo-local package dependencies?

[alexjfno1]

I have a Yarn Workspace Monorepo setup like the following:

|- package.json
|- yarn.lock
|- packageA/
   |- package.json
|- packageB/
   |- package.json
|- packageC/
   |- package.json

packageA has packageB and packageC listed in it's package.json file. When I run snyk test --yarn-workspaces I get the following error:

Dependency packageB was not found in yarn.lock. Your package.json and yarn.lock are probably out of sync. Please run "yarn install" and try again.

I can get around the problem by using --strict-out-of-sync=false but wondered if I could get away with not using that workaround. It may not be the right place to ask but when I integrate my project through the website using the GitHub integration I also get a similar error and I can't find a way to configure it to use --strict-out-of-sync=false.

[macku]

Hi, are there any short term plans to improve that issue? In Atlassian, we are struggling with that problem in some of the open-source projects:

• AUI
• CSE

You should have access to clone the repositories and build the projects so you can easily reproduce the problem if you remove the --strict-out-of-sync=false flag.

Thanks Maciej Adamczak Atlassian Developer

[lili2311]

hi @macku I've forwarded this to the relevant team for consideration. Will keep you posted.

[lili2311]

@alexjfno1 You can set the same out of sync setting in UI via Language Settings => JavaScript