Support yarn v2 in Dependency Scanning
NOTE if you are a user who also would like to see this feature, please UPVOTE
If you are a team member commenting on behalf of a user (not ideal, as you can only upvote once!) Please remember to upvote and include as much information (what they are trying to solve for, their setup) as possible in addition to a salesforce or zendesk link.
Problem to solve
Support Yarn v2 - see #233911 (closed)
We can also support Yarn v3 in one go since this both lock files have the same format
User experience goal
Make the existing Gemnasium Yarn parser capable of parsing lock files for yarn v2 and v3. The parser should be able to make the dinstiction between Yarn Classic and Berry and treat the lock files accordingly. By Yarn berry we refer to Yarn versions
It seems like yarn v2 and yarn v3 files have the same structure. This means we could possibly introduce support for both in one go. In this first iteration we will not be supporting:
- workspaces: that means that workspaces will not show up in the generated report
- dependency paths: that means we will not be creating a dependency graph which can be used to show information like dependency paths in the UI
- remediation for berry lock files: remediation will be disabled for berry lock files independently of
Create a Yarn v2 test project. Test project should have vulnerabilities.
Extend the Yarn parser so that it can handle yarn v2 lock files.
Unit tests for Yarn parser.
Add integration tests. Update
spec/gemnasium_image_spec.rbto test yarn v2 files.
Make sure the follow MR is landed
Record a demo and upload it in the Unfiltered channel.
We can add more features to the Gemnasium Yarn v2 support. In order to work in iterrations we have extracted the following follow up issues:
- Perform dependency remediation for Yarn berry
- Add support for workspaces in Yarn berry Dependency Scanning
- Add support for Yarn berry dependency paths
- Decide what to do with Yarn berry patch packages
In contrast to Classic lock files, which are not easily parsed, Berry lock files are in YAML format and can be easily parsed with a YAML decoder library. We plan to split the Gemnasium Yarn parser into two sub-components: one for parsing Classic lock files, which can use the existing parser code, and another for Berry lock files. The latter component will be able to parse a YAML file and extract metadata such as the lock file version and package definitions with their versions.
It's important to note that the lock file version is tracked in the metadata section of the Berry lock file, and it should not be confused with the Yarn version. Yarn v2 uses lock file version 4, while Yarn v3 uses lock file version 6. We will throw an error for any lock file version outside of this range. This means that Gemnasium will not be compatible with future versions of Yarn.
Finally, Yarn v2 and v3 lock files have the same structure and hence we can parse them in one go providing, minimal support for both.
Permissions and Security
We need to update the relevant section in the documentation, saying that we do support Yarn v2 and v3 now.
EDIT: Support for Yarn v2 and v3 was introduced in GitLab 15.11, however, this feature is also available to versions of GitLab >= 15.0.
Availability & Testing
The following items need to be processed:
- Unit tests for both Yarn v2 and v3 lock files.
- Integration tests using rspec for Yarn v2. If time permits we can also add tests for Yarn v3. Otherwise we can do it as part of 351841
- Test projects should be created for Yarn v2 and v3. These projects need to follow the test-common guidelines.
What does success look like, and how can we measure that?
What is the type of buyer?
Is this a cross-stage feature?
Links / references
This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.