-
Notifications
You must be signed in to change notification settings - Fork 81
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
Add a sherif
monorepo linter to the CI
#452
Conversation
5babfdd
to
f16e4ff
Compare
Pull Request Test Coverage Report for Build 9807067578Details
💛 - Coveralls |
Pull Request Test Coverage Report for Build 9807067573Details
💛 - Coveralls |
f16e4ff
to
cf054ff
Compare
Pull Request Test Coverage Report for Build 9807114818Details
💛 - Coveralls |
Pull Request Test Coverage Report for Build 9807114812Details
💛 - Coveralls |
sherif
monorepo linter to the CI
cf054ff
to
2716468
Compare
Pull Request Test Coverage Report for Build 9807254097Details
💛 - Coveralls |
Pull Request Test Coverage Report for Build 9807254091Details
💛 - Coveralls |
modules/4337/package.json
Outdated
@@ -47,15 +47,15 @@ | |||
"url": "https://github.com/safe-global/safe-modules/issues" | |||
}, | |||
"devDependencies": { | |||
"@account-abstraction/contracts": "^0.7.0", | |||
"@account-abstraction/contracts": "0.7.0", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this be a dependency? I think we import types from it when building the contract:
safe-modules/modules/4337/contracts/Safe4337Module.sol
Lines 6 to 9 in bb5e1f7
import {IAccount} from "@account-abstraction/contracts/interfaces/IAccount.sol"; | |
import {PackedUserOperation} from "@account-abstraction/contracts/interfaces/PackedUserOperation.sol"; | |
import {_packValidationData} from "@account-abstraction/contracts/core/Helpers.sol"; | |
import {UserOperationLib} from "@account-abstraction/contracts/core/UserOperationLib.sol"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes sir.
modules/recovery/package.json
Outdated
"yargs": "^17.7.2" | ||
}, | ||
"dependencies": { | ||
"candide-contracts": "github:5afe/CandideWalletContracts#113d3c059e039e332637e8f686d9cbd505f1e738", | ||
"@openzeppelin/contracts": "=4.9.6", | ||
"@safe-global/safe-contracts": "=1.4.1-build.0" | ||
"@safe-global/safe-contracts": "^1.4.1-build.0" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if we should use exact dependencies for these:
"@safe-global/safe-contracts": "^1.4.1-build.0" | |
"@safe-global/safe-contracts": "=1.4.1-build.0" |
They affect the build and ultimately the bytecode - so not doing so could lead to issues where packages that depend on the contracts here build with different bytecode than what the contract build originally.
Same applies for other @safe-global/safe-contracts
and @account-abstraction/contracts
dependencies elsewhere.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So I've done this in the recovery package (technically, we shouldn't have this dependency here, but it's listed as a dev dependency in their repo) and the 4337 one. I proposed a change to them in our shared Slack channel.
.github/workflows/ci.yml
Outdated
pnpm install | ||
pnpm run fmt:global-check | ||
# -i is to ignore packages that are expected to have multiple versions across the workspace | ||
npx sherif@latest -i @openzeppelin/contracts |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not a fan of this - it means that CI can break from one run to another because of new sherif
rules.
Why not add it as a dependency to the root of the repository? It can even be part of the fmt:global-check
in order to be easier to run locally.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is their recommended way of running it: https://github.com/QuiiBz/sherif
I agree using latest
is a mistake, I'll pin it to a specific version.
It can even be part of the fmt:global-check
It can be, but I am unsure if it's related to formatting 🤷
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It can be, but I am unsure if it's related to formatting 🤷
😅 - it definitely isn't. What I meant more was that we can use NPM scripts to run both checks with a single command. A wise @mmv08 once taught me that this is the way :P
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pinned the version sir
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I migrated it to the package.json file, and one thing that I missed straight away is the comments 🙈 I have no way to explain what the -i
flag does and why certain packages are excluded
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
git blame
😛
True that JSON doesn't allow for comments which is annoying 😞
Pull Request Test Coverage Report for Build 9808488628Details
💛 - Coveralls |
"permissionless": "0.1.29", | ||
"viem": "2.12.5" | ||
}, | ||
"devDependencies": { | ||
"@types/node": "20.14.0", | ||
"@types/node": "^20.14.8", | ||
"tsx": "4.11.0", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unrelated nit that I'm just noticing now: it feels weird that we write dependencies differently for different packages in our repository. Here, we are using "x.y.z", while in others we are using "^x.y.z", even though there is nothing special about these dependencies for expressing them differently from a semver perspective.
Not for this PR, just something that I wanted to bring up.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe there's a purpose, the problem is that there are no comments allowed in the package.json, so that knowledge may be lost. There are some hacky solutions though: https://stackoverflow.com/questions/14221579/how-do-i-add-comments-to-package-json-for-npm-install
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These packages are getting pinned by the lock file. The places where versioning matters more are for dependencies
, because those get transitively installed.
I think that git blame
might be able to include documentation for these.
3bbf18c
to
d081be9
Compare
package.json
Outdated
@@ -39,6 +42,7 @@ | |||
"eslint-plugin-react-refresh": "^0.4.7", | |||
"prettier": "^3.3.0", | |||
"prettier-plugin-solidity": "^1.3.1", | |||
"rimraf": "^5.0.7" | |||
"rimraf": "^5.0.7", | |||
"sherif": "0.9.0" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"sherif": "0.9.0" | |
"sherif": "^0.9.0" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
They may not be following semver right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Don't think that matters - we have a lock file, so the version gets pinned anyway. Also I think this version should follow semver (not super clear, but the docs say that it "must be parseable by node-semver", which itself is a semantic versioning package for NodeJS).
One more question here: #452 (comment), but approving to reduce back-and-forth. |
d081be9
to
1582795
Compare
Pull Request Test Coverage Report for Build 9842375074Details
💛 - Coveralls |
modules/passkey/package.json
Outdated
"@openzeppelin/contracts": "^5.0.0", | ||
"@safe-global/safe-contracts": "^1.4.1-build.0", | ||
"@account-abstraction/contracts": "0.7.0", | ||
"@openzeppelin/contracts": "^5.0.2", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a transitive dependency from account-abstraction (whose package has a bug and doesn't correctly include the contracts as a dependency) and uses version 5.0.0:
I would suggest marking this as:
"@openzeppelin/contracts": "^5.0.2", | |
"@openzeppelin/contracts": "=5.0.0", |
To indicate this is an exact version on purpose.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, they do include it as a dependency (I created a PR to fix it). We have it because hardhat can't resolve pnpm modules correctly: NomicFoundation/hardhat#4292
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, good find.
Should we use 5.0.0 though, so it matches the version in the repository?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We only use the AA dependency in tests and do not depend on the same bytecode, so I think it's fine. Openzeppelin package is also following semver so I think it's in the allowed version range.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oops, I accidentally commited the fix. Still good with me though
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wait - if its only used in tests, then I think it should be a devDependency
. I'm so confused 😭
Co-authored-by: Nicholas Rodrigues Lordello <nick@safe.global>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Approving once again - I think some of the discussions around dependencies should happen, but they don't need to for this PR to merge since this is only about adding sherif
for linting (so I'm sorry I keep on bringing them up 🙈).
The PR introduces the 'sherif' linter, which is an opinionated, zero-config linter designed specifically for JavaScript monorepos. This addition aims to improve code quality and standardize development practices across the safe-modules project.
CI Integration:
The PR adds 'sherif' to the CI workflow. This ensures that the linter runs automatically on pull requests, helping to catch potential issues early in the development process.
Linter Features:
'Sherif' offers several features:
Found and fixed issues: