cli
cli copied to clipboard
Snyk CLI appears to still check package.json dependencies/devDependencies even when provided with a yarn.lock
-
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.
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
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
Hi Denis,
thanks a lot, with --dev
it's working 👍
edit: it turns out that it is only checking the dev dependencies :/
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
.
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
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):
- copy yarn.lock in each directory that contains a package.json file
- 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
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.
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
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
ordevDependencies
. - 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?
👋 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.
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?
@lili2311 Is there any progress here?
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.
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?
👋 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.
👋 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 🎉
👋 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.
@marcelkottmann @karthikiyengar @ebickle please let me know if this covers your use-cases on CLI?
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.
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.
@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 athttps://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
@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?
@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 :)
"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.
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.
Hi Lili, is there any update on handling repo-local package dependencies?
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
.
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:
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
hi @macku I've forwarded this to the relevant team for consideration. Will keep you posted.
@alexjfno1 You can set the same out of sync setting in UI via Language Settings => JavaScript