[FOLIO-1790] Check stripes framework for duplicate dependencies in CI Created: 07/Feb/19  Updated: 03/Jun/20  Resolved: 23/Apr/19

Status: Closed
Project: FOLIO
Components: None
Affects versions: None
Fix versions: None

Type: Task Priority: P3
Reporter: Matthew Jones Assignee: Ian Hardy
Resolution: Done Votes: 0
Labels: ci, platform-backlog
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Issue links:
Relates
relates to STCOR-222 define the stripes-duplicate-plugin l... Closed
relates to STRIPES-566 Stripes framework quality gates Closed
Sprint: CP: sprint 62, Core: Platform - Sprint 61
Story Points: 2
Development Team: Core: Platform

 Description   

As a safeguard to releasing new versions of stripes (framework), we should ensure that any given version of stripes does not pull down duplicate stripes-* dependencies. This check can be performed by running yarn why (or inspecting the lock file) after a yarn install of stripes.

For example, repeat yarn why @folio/stripes-[name] for each of the stripes modules.

This is an example of expected output for yarn why @folio/stripes-components. Note there is only one reference to Found "@folio/stripes-components@5.0.2"

$ yarn why @folio/stripes-components
yarn why v1.12.3
[1/4]   Why do we have the module "@folio/stripes-components"...?
[2/4]   Initialising dependency graph...
[3/4]   Finding dependency...
[4/4]   Calculating file sizes...
=> Found "@folio/stripes-components@5.0.2"
info Has been hoisted to "@folio/stripes-components"
info Reasons this module exists
   - Specified in "dependencies"
   - Hoisted from "@folio#stripes-core#@folio#stripes-components"
   - Hoisted from "@folio#stripes-smart-components#@folio#stripes-components"
   - Hoisted from "@folio#stripes-form#@folio#stripes-components"
info Disk size without dependencies: "7.86MB"
info Disk size with unique dependencies: "26.2MB"
info Disk size with transitive dependencies: "62.79MB"
info Number of shared dependencies: 48
  Done in 1.12s.

Here is an example of a duplication. This one should result in a failure:

$ yarn why @folio/stripes-components
yarn why v1.12.3
[1/4]   Why do we have the module "@folio/stripes-components"...?
[2/4]   Initialising dependency graph...
[3/4]   Finding dependency...
[4/4]   Calculating file sizes...
=> Found "@folio/stripes-components@5.0.2"
info Has been hoisted to "@folio/stripes-components"
info Reasons this module exists
   - Specified in "dependencies"
   - Hoisted from "@folio#stripes-core#@folio#stripes-components"
   - Hoisted from "@folio#stripes-smart-components#@folio#stripes-components"
   - Hoisted from "@folio#stripes-smart-components#@folio#stripes-form#@folio#stripes-components"
info Disk size without dependencies: "7.86MB"
info Disk size with unique dependencies: "26.11MB"
info Disk size with transitive dependencies: "62.71MB"
info Number of shared dependencies: 48
=> Found "@folio/stripes-form#@folio/stripes-components@4.5.1"
info Reasons this module exists
   - "@folio#stripes-form" depends on it
   - Hoisted from "@folio#stripes-form#@folio#stripes-core#@folio#stripes-components"
info Disk size without dependencies: "7.26MB"
info Disk size with unique dependencies: "26.05MB"
info Disk size with transitive dependencies: "62.64MB"
info Number of shared dependencies: 50
  Done in 1.68s.

In this case yarn is reporting two versions of stripes-components:

=> Found "@folio/stripes-components@5.0.2"
=> Found "@folio/stripes-form#@folio/stripes-components@4.5.1"

Ideally we prevent a merge to master if such failures are present.



 Comments   
Comment by Matthew Jones [ 07/Feb/19 ]

Jakub Skoczen John Malconian, FYI. This quality check was discussed following the stripes 2.0 release. I've added "ci" and "platform-backlog" labels. Would you apply any others necessary for it to be considered for future planning/work?

Comment by John Malconian [ 07/Feb/19 ]

Thanks, Matthew Jones. I added the Development Team as well so it should appear in our backlog for further "grooming".

Comment by Matthew Jones [ 14/Feb/19 ]

I removed my suggestion from the description that this would also be a good check for platform-* builds. This is because a platform could have multiple copies of stripes-* modules downloaded to the node modules directory , but that does not necessarily mean duplicates are included in the bundle. For instance, the platform's devDependency on stripes-cli could pull down an extra copy of stripes-core. However, when the platform provides its own copy (via stripes framework), the CLI will use that instead.

The stripes framework, on the other hand, should not be contributing to duplication within the modules it brings in. Therefore this check described here should be limited to validating stripes and not the platforms. For platforms, we can configure the stripes-duplicate-plugin to error on such duplicates ( STCOR-222 Closed ). The plugin captures only those modules that are duplicated in the bundle and not on disk.

(also FOLIO-1569 Open is somewhat related, with regards to running quality checks on a platform)

Comment by John Malconian [ 08/Apr/19 ]

Ian Hardy - Try to keep this as a self-contained script/function in jenkins-pipeline-libs/vars. That way we can call it from multiple places if needed in the future.

Comment by Ian Hardy [ 22/Apr/19 ]

Matthew Jones - Added an optional function to check yarn.lock for duplicate stripes-* modules. It runs `yarn why` and causes a build failure if a duplicate is found.

Success looks like this: https://jenkins-aws.indexdata.com/job/folio-org/job/stripes/job/folio-1790-testing/6/console
Failure looks like this: https://jenkins-aws.indexdata.com/job/folio-org/job/stripes/job/folio-1790-testing/7/console

I can turn on this quality check in the stripes Jenkins file if you're ready.

Generated at Thu Feb 08 23:15:56 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.