devDeps: update @metamask/eslint-config* from 11 to 12
#165
Conversation
legobeat
commented
Aug 31, 2023
•
legobeat
commented
- Bump @metamask/eslint-config-typescript from 11.1.0 to 12.1.0 #159
- Bump @metamask/eslint-config-nodejs from 11.1.0 to 12.1.0 #160
- Align peerDependency requirements
- lint fix/ignore/disable.
|
New, updated, and removed dependencies detected. Learn more about Socket for GitHub ↗︎
🚮 Removed packages: [email protected] |
|
👍 Dependency issues cleared. Learn more about Socket for GitHub ↗︎ This PR previously contained dependency changes with security issues that have been resolved, removed, or ignored. |
fs access ok |
maintainership ok |
legobeat
force-pushed
the
devdeps-eslint
branch
2 times, most recently
from
bc32f64 to
c109492
Compare
Bumps [@metamask/eslint-config-nodejs](https://github.com/MetaMask/eslint-config) from 11.1.0 to 12.1.0. - [Release notes](https://github.com/MetaMask/eslint-config/releases) - [Commits](MetaMask/eslint-config@v11.1.0...v12.1.0) --- updated-dependencies: - dependency-name: "@metamask/eslint-config-nodejs" dependency-type: direct:development update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <[email protected]>
Bumps [@metamask/eslint-config-typescript](https://github.com/MetaMask/eslint-config) from 11.1.0 to 12.1.0. - [Release notes](https://github.com/MetaMask/eslint-config/releases) - [Commits](MetaMask/eslint-config@v11.1.0...v12.1.0) --- updated-dependencies: - dependency-name: "@metamask/eslint-config-typescript" dependency-type: direct:development update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <[email protected]>
legobeat
force-pushed
the
devdeps-eslint
branch
from
c109492 to
dc953df
Compare
| @@ -7,6 +7,9 @@ module.exports = { | |||
| { | |||
| files: ['*.ts'], | |||
| extends: ['@metamask/eslint-config-typescript'], | |||
| rules: { | |||
| '@typescript-eslint/consistent-type-imports': 'off', | |||
There was a problem hiding this comment.
Can we solve this, rather than disabling the rule?
There was a problem hiding this comment.
I do believe so, but I consider that separate from the package upgrade.
There was a problem hiding this comment.
But feel free to add on a commit if you think it fits better here.
There was a problem hiding this comment.
Hmm. I'm having second thoughts about always deferring lint violation fixes when we upgrade lint packages by disabling ESLint rules like this. The thing is that whether we make these fixes now or later, we still have to make them, and it's easy to forget about them in the swath of other maintenance tasks we need to make time for. I understand that in other packages (e.g. core), we chose to disable various ESLint rules in order to lighten the load of the resulting diff, and so the compromise we made was acceptable. But I wonder if it in smaller libraries like this it wouldn't add too much to the diff to address violations for this rule at the same time as the upgrade?
|
This was squashed, resubmitted and merged as duplicate #169 |
