-
Notifications
You must be signed in to change notification settings - Fork 12k
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 custom linting rules #4132
Add custom linting rules #4132
Conversation
This comment was marked as off-topic.
This comment was marked as off-topic.
Nice @lhemerly! This is appreciated. Is it possible to have the "plugin" as a JS file in this repository, rather than a separate npm package? I would like to do that as it will be easier for us to maintain and evolve. |
As far as I know it is not possible right now as you can't set-up the plugin path in solhint: It is hardcoded to look up for I may try a PR on Solhint for custom plugins paths later |
Fixes OpenZeppelin#3919 Add solhint-plugin-ozcontracts to devDependencies Add ozonctracts to .solhint.json plugins Add oz-contracts-custom to .solhint.json rules #### PR Checklist - [ x] Tests - [ ] Documentation - [ ] Changeset entry (run `npx changeset add`)
Just a follow up, PR in solhint created: |
Maybe we could make it work by defining the package locally in the repo? Not exactly but sort of monorepo style. |
The way I can imagine making it work as solhint is right now is to take the "solhint-plugin-ozcontracts" folder inside node_modules out of the gitignore and work with the .js file there as part of the repo. The way npm (or yarn) install works it won't change that folder as long as we remove and keep it out of package.json. If you think it is ok to go with that I can make the necessary changes |
Putting in |
@lhemerly I've vendored your plugin into this repository like I suggested. This should be a great start to begin to build more custom linting rules. Thanks! |
@Amxx @ernestognw Note that this will allow us to have internal constants without leading underscore moving forward. |
} | ||
}, | ||
|
||
// TODO: re-enable and fix |
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 have some code that causes this rule to fail so I'm proposing to merge and enable it later.
Co-authored-by: Hadrien Croubois <[email protected]>
if (!/^_/.test(node.name)) { | ||
this.error(node, 'Private variables must be prefixed with underscore'); | ||
} | ||
} |
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 we also have some rule that if the stateVar is constantOrImmutable, then it must NOT start with an underscore ? or do we accept both ?
} | |
} else if (node.isStateVar && constantOrImmutable) { | |
if (/^_/.test(node.name)) { | |
this.error(node, 'Constant and immutable variables should not be prefixed with underscore'); | |
} | |
} |
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 agree, but this causes the rule to fail in a few places.
I added the rule but commented it out, and I'd propose to do another PR next week fixing those things. Does this sound ok?
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 we will have 2 follow up PRs that :
- enable the rule
- fix the code
?
That sounds ok
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.
Yeah or just one PR doing the two.
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 the rule should also check that the name is capitalized.
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.
That should be already handled by the casing rules in solhint.config.js
, specifically const-name-snakecase
.
Just an update, development branch in solhint adjusted plugins to be in any path: |
|
||
module.exports = { | ||
plugins: ['openzeppelin'], | ||
rules: Object.fromEntries(rules.map(r => [r, 'error'])), |
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.
Why not define it like an object?
const rules = {
'no-unused-vars': 'error',
...
}
Not a blocker because everything shows an "error", I just wanted to point out that the array doesn't seem to be needed
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 need to use fromEntries
in some way because we get the names of the custom rules dynamically:
customRules.map(r => `openzeppelin/${r.ruleId}`)
The rest could be an object, but I had a feeling that this was clearer? Let me know if it's too confusing.
Congrats, your important contribution to this open-source project has earned you a GitPOAP! GitPOAP: 2023 OpenZeppelin Contracts Contributor: Head to gitpoap.io & connect your GitHub account to mint! Learn more about GitPOAPs here. |
Fixes #3919
Adds a custom plugin for Solhint that implements the project's Solidity guidelines.