[FOLIO-3477] FE: update outdated dependencies Created: 22/Apr/22  Updated: 17/May/22  Resolved: 17/May/22

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

Type: Tech Debt Priority: P3
Reporter: Khalilah Gambrell Assignee: Priyanka Terala
Resolution: Done Votes: 0
Labels: epam-spitfire, front-end
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Attachments: PNG File image-2022-05-10-16-54-02-856.png     PNG File image-2022-05-11-16-24-20-853.png     PNG File image-2022-05-11-16-26-57-492.png    
Issue links:
Cloners
is cloned by UIMARCAUTH-145 FE: update outdated dependencies Closed
is cloned by UIMPROF-69 FE: update outdated dependencies Closed
Defines
defines UXPROD-3436 Spitfire - Morning Glory R2 2022 Enh... Closed
Relates
relates to STRIPES-675 update outdated dependencies Open
relates to STCOR-510 update outdated dependencies Closed
relates to STCOR-614 update outdated dependencies Closed
Sprint: Spitfire Sprint 140, Spitfire Sprint 139
Story Points: 3
Development Team: Spitfire
Release: Morning Glory (R2 2022)
RCA Group: TBD

 Description   

Please do this work for modules owned by Spitfire.

Below requirements were provided by Zak Burke .

  1. Build platform-complete and look at all the pretty build warnings during "Resolving packages" AND pretty build warnings during "Linking dependencies". Many modules have bad peer-deps and rely on hoisting.
  2. See if we can update any of those deps. 
  3. Please review

    STRIPES-675 Open for more details -  update outdated dependencies 
  4. During "Resolving packages" Many are transitive deps so it may not be possible to resolve them all. 
  5. During "Linking dependencies" Many modules have bad peer-deps and rely on hoisting. 

Additional notes from Zak: Some of these warnings (classnames, prop-types, prop-types-extra) should be straight deps, not peers. Some probably should be peers, but that means adding them to the platform and making them peers in modules where they are currently direct deps. This'll take a keen eye.

 

Also review this story  STCOR-614 Closed (replacing STCOR-510 Closed which is now outdated)



 Comments   
Comment by Priyanka Terala [ 10/May/22 ]

Zak Burke
1. After talking to Denys Bohdan, I got to know that, sometime ago, we have pinned the version of moment package to "moment": "~2.24.0", should be upgrade it to 2.29.0 now?

2. Although I update the package versions appropriately(in local), the linking warnings are still visible. Please find the reference below -

Comment by Zak Burke [ 10/May/22 ]

Priyanka Terala, yes, moment can be unpinned from ~2.24.0 and bumped to ^2.29.0. I don't remember what the 2.25.0 bug was, but I remember it being completely unusable for us at the time.

The rest of those "unmeet peer react..." warnings are because your workspace's package.json is missing the deps that platform-complete's package.json provides. Add those, plus @folio/stripes which will pull in -core, -connect, -stripes-smart-components etc. Copy those into the workspace's package.json and most warnings will disappear. If the warnings are still present, then it is an indication of something that needs to be fixed, e.g.

  • an app lists a peer-dep that is not provided by the platform. IIRC some apps do this with prop-types; it needs to be a direct-dep of the app.
  • an app has a dep on something that is not compatible with the version provided by the platform. Some stripes-components deps are only compatible with react 14-16 but we are on 17; the app needs to upgrade to a compatible version or find a replacement. Sometimes upgrading to a compatible version is easy because the only breaking change was "dropping support for react <17" and you can just update the major version. Sometimes there is no compatible version or there are additional breaking changes, e.g. kopy v8 -> v9 for stripes-cli, in which case file a separate ticket. "@bigtest/react@0.1.2" is an example of this kind of warning in your screenshot above.
Comment by Priyanka Terala [ 11/May/22 ]

Instead of using the platform workspace approach, I had cloned "Platform-Complete", checked out the branch "snapshot" and ran "yarn install". Here I could see
1. no warnings while resolving the packages.

2. three warnings(pertaining to those modules owned by Spitfire Team ) while linking dependencies 

Zak Burke Could you please help me with the exact steps to build "platform-complete", if this is not the correct approach?

Comment by Zak Burke [ 11/May/22 ]

Priyanka Terala, yarn install within platform-complete will pull in platform-complete's deps (and so on transitively, i.e. deps fo deps, deps of deps of deps...) and its dev-deps. It will not pull in dev-deps transitively. Thus, things we find out about with this kind of install are (1) incorrect dependencies from any module and (2) incorrect dev-deps from the platform. WRT your questions above:

  1. great!
  2. this tells us several things:
    1. ui-marc-authorities has an incorrectly specified peer-dep on core-js. (a) core-js is not a direct dep of the platform and therefore cannot be a peer-dep of any UI module. (b) core-js, AFAIK, is only a dev dep, so never should have been added as a peer-dep to begin with.
    2. ui-myprofile has an incorrectly specified dep on eslint-import-resolver-webpack, which itself has peer-deps on eslint-plugin-import and webpack. eslint-import-resolver-webpack should be a dev-dep rather than a direct-dep because it is not a production dependency. This requires a bit more investigation. It's clear that eslint-import-resolver-webpack should not be a direct-dep, that part is unambiguously wrong, but moving it to dev-dep without adding its peers (eslint-plugin-import and webpack) as dev-deps will just move the warning without resolving it. But, we don't want webpack to be a devdep of every UI module (we want to let stripes-cli manage that via stripes-webpack) so we need to figure out what problem this library is solving and figure out if there's a different way to solve it.

If you want to learn about incorrect dev-deps in an individual module, you need to clone that module and run yarn install for it. Just as yarn install in a platform can tell us about problems with the platform's dev-deps, yarn install in a UI app can tell us about problems with the app's dev-deps.

Comment by Priyanka Terala [ 12/May/22 ]

Zak Burke
Thank you for your inputs!

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