Add option to ignore out of sync lock files

[MaelGNM]

What does this change?

Because of how the support dotcom components packages are structured the snyk task fails with the following error:

OutOfSyncError: Dependency @sdc/shared 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 PR adds support for the --strict-out-of-sync option for snyk monitor.
It adds a new optional boolean parameter to this task name IGNORE_OUT_OF_SYNC, if set to true it sets adds the option --strict-out-of-sync=false to the snyk command.

The default for --strict-out-of-sync is true so setting IGNORE_OUT_OF_SYNC to false does nothing.

This option is only available for npm and yarn projects.

Snyk docs.

How to test

I will use this branch's version of the task to test the support-doctom-components snyk integration and take it from there.
-> This solved the issue

How can we measure success?

Have we considered potential risks?

[tomrf1]

👍

[akash1810]

I do not think this is correct, and we should instead ensure the lock files are in sync. Node package managers have flags to support this in CI.

In yarn, we have yarn install --frozen-lockfile:

If you need reproducible dependencies, which is usually the case with the continuous integration systems, you should pass --frozen-lockfile flag.

In NPM, we have npm ci:

This command is similar to npm install, except it's meant to be used in automated environments such as test platforms, continuous integration, and deployment -- or any situation where you want to make sure you're doing a clean install of your dependencies.

I think we should use these flags when installing dependencies in CI, so that the build fails if the lock file is out of date, resulting in our keeping it up to date. This also results in CI becoming more deterministic, as the versions of (direct, and transitive) dependencies installed during the build will exactly match those used locally when developing a change.

[akash1810]

I think this is a duplicate of #42?

[MaelGNM]

I do not think this is correct, and we should instead ensure the lock files are in sync.

@akash1810 The issue is that the out of sync package is not an NPM package but another yarn workspace from this repo.

In support-dotcom-components we have shared, which both server and modules depend on. When Snyk tries to monitor server (and modules) it finds a reference to @sdc/shared but that's of course not in the lock file so it throws the out of sync error.

We have a project to move modules out of this repo and we could then refactor to remove shared but that won't be happening until next quarter at the earliest. In the meantime we would need this as a workaround to make sure we can monitor the repository.