Snyk: Question : why Snyk isn't only in dev dependencies ?

[Aarbel]

Hi Snyk teams,

Is there a reason why Snyk is automatically added in package.json { dependencies: … } and not in { devDependencies: … } just for vulnerable package updates, and testing if everything works with these updates ?

Is there any interest to use the Snyk package under production ?

Thanks a lot !

[odinn1984]

Hi! Thanks for the question.

Snyk is also used to automatically patch production environments using snyk protect to be able to run that before launching your production environment snyk has to be installed as a production dependency.

This is why we chose to go that path.

Hope that answers the question, have a good week!

[Aarbel]

Ok thanks @odinn1984 ;)

[tswaters]

Hi,

For libraries in npm, this can end up bringing ~5mb of packages if you require a library that uses synk.

Please consider moving synk to a devDependency.

[sean256]

@odinn1984

Snyk is also used to automatically patch production environments using snyk protect to be able to run that before launching your production environment snyk has to be installed as a production dependency.

How does this work? This would require devs to script it's call from the production machine before launching. And once a typically node app is running it's not going to "re-launch" unless it crashes. And there are lot of node use cases where "patching in production" isn't an option, like AWS lambdas or election apps or react-native or npm modules or static deployed sites...

Ensuring code is safe should be done in a ci/cd pipeline. Not "in production".

[mikeprimm-triva]

As the node package.json is as likely to be for a library as a top level component (I know of at least a couple of cases where it IS being used by pure library components), the notion that the 'snyk protect' run is going to be used in production will be a function of the top level component, independent of whether you think that running untested patches in production post CI/CD is a good idea (most people don't). The desire for it to be a 'dependency' vs a 'devDependency' should be a function of the top level deployed component (for example, unless my app, which uses oas-tools, happens to want to use this pattern, the desire and mechanisms by which that would be used would be a function of my code deployment, and not a library component within my app). The top level app is free to add 'snyk' as a dependency, as appropriate, but there is no good way to REMOVE a dependency of a library that isn't actually needed or used by the library itself during production.

Just my $0.02.

[lili2311]

Thanks all for your thoughts on this, we will share this back internally to discuss and explore if there are other options available to allow patching without adding snyk as a dependency.

@mikeprimm-triva @Aarbel I believe you can today have a workaround as following:

1. Disable patches in PRs
   
2. When you have new vulns, use the snyk wizard locally to apply and save the patches to the .snyk file
3. replace the snyk-protect command to be npx snyk protect or yarn snyk protect & remove snyk as a dependency:

  "scripts": {
    "snyk-protect": "npx snyk protect"
  },

You can also repeat step 3 on the PRs that add patches which will keep trying add snyk as a dependency if a patch was applied.