feat: upgrade all dependencies and add new consistent react import rule

[SimeonC]

📦 Published PR as canary version: Canary Versions

✨ Test out this PR locally via:

npm install @tablecheck/babel-preset@1.1.0-canary.47.2032631171.0
npm install @tablecheck/codemods@1.1.0-canary.47.2032631171.0
npm install @tablecheck/commitlint-config@1.1.0-canary.47.2032631171.0
npm install @tablecheck/eslint-config@1.7.0-canary.47.2032631171.0
npm install @tablecheck/eslint-plugin@1.2.0-canary.47.2032631171.0
npm install @tablecheck/scripts@1.11.0-canary.47.2032631171.0
npm install @tablecheck/semantic-release-config@2.5.0-canary.47.2032631171.0
npm install @tablecheck/scripts-utils@1.1.0-canary.47.2032631171.0
# or 
yarn add @tablecheck/babel-preset@1.1.0-canary.47.2032631171.0
yarn add @tablecheck/codemods@1.1.0-canary.47.2032631171.0
yarn add @tablecheck/commitlint-config@1.1.0-canary.47.2032631171.0
yarn add @tablecheck/eslint-config@1.7.0-canary.47.2032631171.0
yarn add @tablecheck/eslint-plugin@1.2.0-canary.47.2032631171.0
yarn add @tablecheck/scripts@1.11.0-canary.47.2032631171.0
yarn add @tablecheck/semantic-release-config@2.5.0-canary.47.2032631171.0
yarn add @tablecheck/scripts-utils@1.1.0-canary.47.2032631171.0

[github-actions]

Unit Test Results

  2 files    9 suites   10s ⏱️
55 tests 55 ✔️ 0 💤 0 ❌

Results for commit da53a2e.

♻️ This comment has been updated with latest results.

[wahidfarid]

Out of scope of this PR, but trying to understand something 🙇

judging by the amount of packages that use ^ it's an intentional decision. If we are always using explicit version numbers in our apps to avoid breakage, shouldn't we do the same in underlying packages like the tc react system? 🤔 otherwise possible breaking changes can propagate from here into projects that use it

[tablecheck-public-automation]

🚀 PR was released in @tablecheck/babel-preset@1.1.0, @tablecheck/codemods@1.1.0, @tablecheck/commitlint-config@1.1.0, @tablecheck/eslint-config@1.7.0, @tablecheck/eslint-plugin@1.2.0, @tablecheck/scripts-utils@1.1.0, @tablecheck/scripts@1.11.0, @tablecheck/semantic-release-config@2.5.0 🚀

[SimeonC]

Out of scope of this PR, but trying to understand something 🙇

judging by the amount of packages that use ^ it's an intentional decision. If we are always using explicit version numbers in our apps to avoid breakage, shouldn't we do the same in underlying packages like the tc react system? 🤔 otherwise possible breaking changes can propagate from here into projects that use it

We used to use explicit version numbers here too for that reason, but normally we found that that approach made it much harder to get small updates out for security or similar as we'd have to jump through the extra hoops. We decided (I decided?) that the security level stuff is handled by auditjs nicely. As for breaking changes - the versions get locked in package-lock.json files of the projects and with newer versions of npm don't update sub-deps unless you forcibly update them.

TLDR; the risk was determined to be smaller than the effort needed to constantly update them if needed.