Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[CCI] Update dependencies #609

Conversation

andreymyssak
Copy link
Collaborator

@andreymyssak andreymyssak commented Mar 20, 2023

Description

Update dependencies that do not lead to breaking changes

yo dependency will be updated in the scope of #599
webpack dependencies will be updated in the scope of #587

Results of yarn install

yarn install v1.22.19
[1/4] 🔍  Resolving packages...
warning Resolution field "trim@0.0.3" is incompatible with requested version "trim@0.0.1"
[2/4] 🚚  Fetching packages...
warning Pattern ["gonzales-pe-sl@github:srowhani/gonzales-pe#dev"] is trying to unpack in the same destination "/Users/andreymyssak/Library/Caches/Yarn/v6/npm-gonzales-pe-sl-4.2.3/node_modules/gonzales-pe-sl" as pattern ["gonzales-pe-sl@^4.2.3"]. This could result in non-deterministic behavior, skipping.
[3/4] 🔗  Linking dependencies...
warning " > @elastic/eslint-config-kibana@0.15.0" has incorrect peer dependency "babel-eslint@^8.0.0".
warning " > @elastic/eslint-config-kibana@0.15.0" has incorrect peer dependency "eslint@^4.1.0".
warning " > @elastic/eslint-config-kibana@0.15.0" has incorrect peer dependency "eslint-plugin-babel@^4.1.1".
warning " > @elastic/eslint-config-kibana@0.15.0" has incorrect peer dependency "eslint-plugin-jest@^21.0.0".
warning " > @elastic/eslint-config-kibana@0.15.0" has incorrect peer dependency "eslint-plugin-mocha@^4.9.0".
warning "react-view > @miksu/prettier > angular-estree-parser@1.1.5" has unmet peer dependency "@angular/compiler@^6.0.0 || ^7.0.0".
warning "react-view > @miksu/prettier > remark-math@1.0.4" has incorrect peer dependency "remark-parse@^3.0.0 || ^4.0.0 || ^5.0.0".
warning "react-view > @miksu/prettier > yaml-unist-parser@1.0.0" has unmet peer dependency "yaml@^1.0.2".
warning " > sass-extract@2.1.0" has incorrect peer dependency "node-sass@^3.8.0 || 4".
warning " > sass-vars-to-js-loader@2.1.1" has incorrect peer dependency "node-sass@^4.11.0".
warning "yo > yeoman-environment@3.10.0" has unmet peer dependency "mem-fs@^1.2.0 || ^2.0.0".
[4/4] 🔨  Building fresh packages...
$ node ./scripts/postinstall.js
✨  Done in 103.21s.

Notes

  • glob dependency higher than v8.1.0 requires Node >= 16
  • get-port dependency higher than v5.1.1 works only with ESM modules
  • fakerjs is no longer supported, I suggest migrating to @faker-js/faker
  • chalk dependency higher than v4.1.2 works only with ESM modules
  • react-docgen-typescript dependency higher than v1.22.0 requires typescript >= 4.3.x
  • puppeteer dependency cannot be updated to v19 because @axe-core/puppeteer has specified puppeteer v18 as a peer dependency.
  • react-focus-on dependency higher than v3.5.0 causes the following error Error: Error: Error: Uncaught [Error: aria-hidden] in the unit tests.
  • react-ace dependency has not been updated because the component in which it is used (OuiCodeEditor) is outdated and will be removed in future releases according to the documentation.

Dependencies that require much effort to update are better moved to separate tasks:

  • eslint + prettier
  • react (it is necessary to migrate to react-testing-library)
  • typescript
  • babel + jest
  • postcss
  • unified + rehype-*, remark-*, vfile, mdast-util-to-hast
  • react-view

Issues Resolved

#594

Check List

  • New functionality includes testing.
  • New functionality has been documented.
  • All tests pass
    • yarn lint
    • yarn test-unit
  • Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

For more information on following Developer Certificate of Origin and signing off your commits, please check here.

@andreymyssak andreymyssak requested a review from a team as a code owner March 20, 2023 04:59
@andreymyssak
Copy link
Collaborator Author

andreymyssak commented Mar 20, 2023

@BSFishy At the moment dependencies and devDependencies are mixed, for example, @types are in dependencies, should I solve this problem in the current PR?

@andreymyssak andreymyssak changed the title [CCI] Update dependencies (#594) [CCI] Update dependencies Mar 20, 2023
@andreymyssak andreymyssak force-pushed the 594-update-dependencies branch 2 times, most recently from 84424d9 to fe93252 Compare March 20, 2023 07:08
@andreymyssak
Copy link
Collaborator Author

I haven't had a chance to have a look at all resolutions in the package.json yet, I don't think there is much I can change there, so for now the code is ready for review

@ashwin-pc ashwin-pc added the CCI College Contributor Initiative label Mar 21, 2023
@ashwin-pc
Copy link
Member

@andreymyssak Thanks for the very clear and detailed PR description. Makes reviewing this a lot easier. Lets keep reorganizing the dependencies for another PR since its easier to review and validate smaller units of change at a time.

@seanneumann
Copy link
Contributor

This is great @andreymyssak. We'll get this reviewed!

@andreymyssak
Copy link
Collaborator Author

I haven't had a chance to have a look at all resolutions in the package.json yet, I don't think there is much I can change there, so for now the code is ready for review

Me and @SergeyMyssak updated the resolutions, we decided not to use **/ as it takes time to figure out which dependency it refers to. For now, if a developer will update react-view, in the dependencies, he/she will immediately see that there are 3 resolutions that can potentially be removed

"react-view/**/ansi-regex": "^5.0.1",
"react-view/**/minimist": "^1.2.6",
"react-view/@miksu/prettier/minimatch": "^3.0.8",

What do you think of this approach?

@BSFishy
Copy link
Contributor

BSFishy commented Mar 21, 2023

Thanks for the work, this looks great. When I wrote #594, I meant for it to be a discovery/analysis task, rather than a task calling for changes. Specifically, I was looking to see what dependencies could be trivially updated (no or minimal changes), which ones could be updated with some work, which ones can or should be removed, which ones should be replaced with other dependencies, etc. However, it looks like a lot of that analysis and discovery already happened in doing the work for this PR. I'd still like for that discovery to be easily accessible, so if you wouldn't mind, do you think you could add a comment on that issue with the analysis and discovery you did for this PR?

@BSFishy At the moment dependencies and devDependencies are mixed, for example, @types are in dependencies, should I solve this problem in the current PR?

As @ashwin-pc mentioned, this should be done in a separate PR. Keeping PRs as small as possible makes it a lot easier to understand and review quickly.

I haven't had a chance to have a look at all resolutions in the package.json yet, I don't think there is much I can change there, so for now the code is ready for review

Me and @SergeyMyssak updated the resolutions, we decided not to use **/ as it takes time to figure out which dependency it refers to. For now, if a developer will update react-view, in the dependencies, he/she will immediately see that there are 3 resolutions that can potentially be removed

"react-view/**/ansi-regex": "^5.0.1",
"react-view/**/minimist": "^1.2.6",
"react-view/@miksu/prettier/minimatch": "^3.0.8",

What do you think of this approach?

That's perfect. Makes it extremely easy to see which resolutions we need to take a look at when updating one of those packages

@andreymyssak
Copy link
Collaborator Author

Thanks for the work, this looks great. When I wrote #594, I meant for it to be a discovery/analysis task, rather than a task calling for changes. Specifically, I was looking to see what dependencies could be trivially updated (no or minimal changes), which ones could be updated with some work, which ones can or should be removed, which ones should be replaced with other dependencies, etc. However, it looks like a lot of that analysis and discovery already happened in doing the work for this PR. I'd still like for that discovery to be easily accessible, so if you wouldn't mind, do you think you could add a comment on that issue with the analysis and discovery you did for this PR?

@BSFishy At the moment dependencies and devDependencies are mixed, for example, @types are in dependencies, should I solve this problem in the current PR?

As @ashwin-pc mentioned, this should be done in a separate PR. Keeping PRs as small as possible makes it a lot easier to understand and review quickly.

I haven't had a chance to have a look at all resolutions in the package.json yet, I don't think there is much I can change there, so for now the code is ready for review

Me and @SergeyMyssak updated the resolutions, we decided not to use **/ as it takes time to figure out which dependency it refers to. For now, if a developer will update react-view, in the dependencies, he/she will immediately see that there are 3 resolutions that can potentially be removed

"react-view/**/ansi-regex": "^5.0.1",
"react-view/**/minimist": "^1.2.6",
"react-view/@miksu/prettier/minimatch": "^3.0.8",

What do you think of this approach?

That's perfect. Makes it extremely easy to see which resolutions we need to take a look at when updating one of those packages

Discovery/analysis based on this PR added to the issue

@BSFishy
Copy link
Contributor

BSFishy commented Mar 22, 2023

Thanks for the analysis. 2 final important questions before reviewing: are there any breaking changes on the engineering side with these changes (i.e. has the public API changed in a breaking way), and are there any changes on the UX side (i.e. will anything change in terms of visuals or the way the components are used by the end user)?

@andreymyssak
Copy link
Collaborator Author

Thanks for the analysis. 2 final important questions before reviewing: are there any breaking changes on the engineering side with these changes (i.e. has the public API changed in a breaking way), and are there any changes on the UX side (i.e. will anything change in terms of visuals or the way the components are used by the end user)?

Component properties and their UI have not changed. The only thing that may have some hidden effect on UX is the updated tabbable dependency, but I checked it, and in my opinion, nothing has changed, unit tests didn't show anything either. In general, I do not see breaking changes that can break the code when updating this library.

@joshuarrrr
Copy link
Member

  • glob dependency higher than v8.1.0 requires Node >= 16

#646

  • get-port dependency higher than v5.1.1 works only with ESM modules
  • chalk dependency higher than v4.1.2 works only with ESM modules

Should we open a follow-up issue to look into alternatives for these?

  • react-focus-on dependency higher than v3.5.0 causes the following error Error: Error: Error: Uncaught [Error: aria-hidden] in the unit tests.

This sounds like it may warrant a follow-up issue

@BSFishy
Copy link
Contributor

BSFishy commented Mar 30, 2023

  • get-port dependency higher than v5.1.1 works only with ESM modules
  • chalk dependency higher than v4.1.2 works only with ESM modules

Should we open a follow-up issue to look into alternatives for these?

I'm currently looking into using Vite instead of Webpack and being ESM module native. Doesn't necessarily change anything now, but wanted to give that context

Copy link
Member

@ashwin-pc ashwin-pc left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@andreymyssak While I started to review this PR, I realized that safely validating the change in a reasonable amount of time would be nearly impossible since there are way too many changes because of too many dependency updates happening at the same time. While I dont expect you to raise an individual PR for each change (since that would be quite tedious and unnecessary), can you split this PR into smaller PR's of 2 kinds.

  1. Group all dependency updates that do not change any code into one
  2. Separate PRs for anything that modifies more than 2 code files. e.g. a separate PR for the SVGO update since it updates a ton of icons.

This way we will be able to get to this PR faster and accept your contribution sooner. The main reason for this is that while there are CI tests that in theory should give us confidence in the change., we dont have any integ tests that make sure that this change does not affect the library in a functional way and that has to be done manually at the moment.

i18ntokens.json Outdated
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why are these values changing for a dependency update PR?

Copy link
Collaborator Author

@andreymyssak andreymyssak Mar 31, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The changes in i18ntokens.json happened after updating the tabbable dependency (I just ran the extract-i18n-strings script after updating it).

I don't know the purpose of this script, but if you run it now in the main branch, this file will be updated because there were some changes in super_date_picker file and extract-i18n-strings script was not run.

"@types/refractor": "^3.0.0",
"@types/resize-observer-browser": "^0.1.5",
"@types/vfile-message": "^2.0.0",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why has this been removed?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why has this been removed?

@types/vfile-message@2.0.0: This is a stub types definition. vfile-message provides its own type definitions

@@ -43,84 +43,93 @@
"url": "https://github.com/opensearch-project/oui.git"
},
"resolutions": {
"**/trim": "0.0.3",
"**/axios": "^0.21.1",
"**/ansi-html": "^0.0.8",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I dont see this resolution anymore

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I dont see this resolution anymore

"**/trim" -> "remark-parse/trim": "0.0.3"
"**/axios" -> "codesandbox/axios": "^0.21.1"
"**/ansi-html" is not used

@andreymyssak
Copy link
Collaborator Author

andreymyssak commented Mar 31, 2023

@andreymyssak While I started to review this PR, I realized that safely validating the change in a reasonable amount of time would be nearly impossible since there are way too many changes because of too many dependency updates happening at the same time. While I dont expect you to raise an individual PR for each change (since that would be quite tedious and unnecessary), can you split this PR into smaller PR's of 2 kinds.

  1. Group all dependency updates that do not change any code into one
  2. Separate PRs for anything that modifies more than 2 code files. e.g. a separate PR for the SVGO update since it updates a ton of icons.

This way we will be able to get to this PR faster and accept your contribution sooner. The main reason for this is that while there are CI tests that in theory should give us confidence in the change., we dont have any integ tests that make sure that this change does not affect the library in a functional way and that has to be done manually at the moment.

The way you suggested to break down dependency updates is really good and makes it much easier to review changes. Below you can find PRs that make some changes to the code:

Dependency PR
@svgr/core #649
tabbable #650
dropzone #651
react-window and react-virtualized-auto-sizer #652
faker #653

Co-authored-by: Sergey Myssak <sergey.myssak@gmail.com>
Signed-off-by: Andrey Myssak <andreymyssak@gmail.com>
@joshuarrrr
Copy link
Member

@andreymyssak My understanding is that we can close this in favor of the other PRs. But if I misunderstood or this needs to be reopened, please do so.

@joshuarrrr joshuarrrr closed this Apr 11, 2023
@andreymyssak
Copy link
Collaborator Author

andreymyssak commented Apr 12, 2023

@andreymyssak My understanding is that we can close this in favor of the other PRs. But if I misunderstood or this needs to be reopened, please do so.

@joshuarrrr This PR was large, so I moved some of the dependencies into separate PRs and left the ones in the current PR that don't make any changes to the code. I don't have a "Reopen pull request" button, should I then make a new PR?

@andreymyssak andreymyssak mentioned this pull request Apr 17, 2023
6 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
CCI College Contributor Initiative
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants