[CCI] Update dependencies

[andreymyssak]

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 "[email protected]" is incompatible with requested version "[email protected]"
[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/[email protected]" has incorrect peer dependency "babel-eslint@^8.0.0".
warning " > @elastic/[email protected]" has incorrect peer dependency "eslint@^4.1.0".
warning " > @elastic/[email protected]" has incorrect peer dependency "eslint-plugin-babel@^4.1.1".
warning " > @elastic/[email protected]" has incorrect peer dependency "eslint-plugin-jest@^21.0.0".
warning " > @elastic/[email protected]" has incorrect peer dependency "eslint-plugin-mocha@^4.9.0".
warning "react-view > @miksu/prettier > [email protected]" has unmet peer dependency "@angular/compiler@^6.0.0 || ^7.0.0".
warning "react-view > @miksu/prettier > [email protected]" has incorrect peer dependency "remark-parse@^3.0.0 || ^4.0.0 || ^5.0.0".
warning "react-view > @miksu/prettier > [email protected]" has unmet peer dependency "yaml@^1.0.2".
warning " > [email protected]" has incorrect peer dependency "node-sass@^3.8.0 || 4".
warning " > [email protected]" has incorrect peer dependency "node-sass@^4.11.0".
warning "yo > [email protected]" 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]

@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]

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]

@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]

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

[andreymyssak]

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]

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]

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]

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]

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]

• 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]

• 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

[ashwin-pc]

@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.

[ashwin-pc]

Why are these values changing for a dependency update PR?

[andreymyssak]

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.

[ashwin-pc]

why has this been removed?

[andreymyssak]

why has this been removed?

@types/[email protected]: This is a stub types definition. vfile-message provides its own type definitions

[ashwin-pc]

I dont see this resolution anymore

[andreymyssak]

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]

@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

[joshuarrrr]

@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.

[andreymyssak]

@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?