[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: |
|
||||||||||||
| 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 (
(also
|
| 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 I can turn on this quality check in the stripes Jenkins file if you're ready. |