Upgrade dependencies
martijnrusschen opened this issue · comments
See
➜ react-datepicker git:(main) yarn outdated
yarn outdated v1.22.19
info Color legend :
"<red>" : Major Update backward-incompatible updates
"<yellow>" : Minor Update backward-compatible features
"<green>" : Patch Update backward-compatible bug fixes
Package Current Wanted Latest Package Type URL
date-fns 3.3.1 3.4.0 3.4.0 dependencies https://github.com/date-fns/date-fns#readme
rollup 2.79.1 2.79.1 4.12.1 devDependencies https://rollupjs.org/
stylelint 15.11.0 15.11.0 16.2.1 devDependencies https://stylelint.io
stylelint-config-standard 34.0.0 34.0.0 36.0.0 devDependencies https://github.com/stylelint/stylelint-config-standard#readme
stylelint-config-standard-scss 11.1.0 11.1.0 13.0.0 devDependencies https://github.com/stylelint-scss/stylelint-config-standard-scss#readme
stylelint-scss 5.3.2 5.3.2 6.2.1 devDependencies https://github.com/stylelint-scss/stylelint-scss#readme
I've updated stylelint related packages. however, there's a bunch of changes required for the rollup upgrade since we're 2 major versions behind. @yuki0410-dev if you have time, could you look into it? I've made a start, but it's not working yet.
@martijnrusschen
I tried that too.
It looks like it worked, but I created a PR as Draft due to insufficient verification of each output file.
🎉
Nice done!
Package Current Wanted Latest Package Type URL
@types/node 16.18.88 16.18.89 20.11.27 devDependencies https://github.com/DefinitelyTyped/DefinitelyTyped/tree/master/types/node
@yuki0410-dev you added this package recently. Any reason to use this specific version?
@martijnrusschen
My apologies.
I introduced Rollup.config.mjs to make it type safe. I had matched it to the version supported by this library, but for our current use it makes more sense to match the node version on the CI where the rollup is run, so we will create a PR soon.
@martijnrusschen
Is there anything else I can help you with?
Given we have a pretty high cove coverage but a couple of glaring blank spots I wonder if we can close the gap and get to full coverage. Thoughts?
I think the coverage of this library is excellent.
We also believe that it is not that difficult to fill in the blank spots in the coverage.
However, even if the coverage is 100%, there are still some omissions and defects occur depending on the combination of Props, as in PR #4603, so if the objective is to identify and reduce defects, I think it is necessary to organize the test once.
I can help if necessary for this repository, but I would like to know your thoughts.