gno-specific code linters #850
Assignees
Labels
help wanted
Want to contribute? We recommend these issues.
📦 🤖 gnovm
Issues or PRs gnovm related
🧾 package/realm
Tag used for new Realms or Packages.
🌱 feature
New update to Gno
Milestone
Comments
ajnavarro
added
🧾 package/realm
moul
added a commit
that referenced
this issue
Jul 31, 2023
This PR introduces a new `gno lint` subcommand, currently focused on checking for the presence of a `gno.mod` file in a package, and it's linked with the CI. In the future, we plan to expand `gno lint` to support additional checks, enhancing its utility for developers and CI integration. Addresses #850 Addresses #927 Related with #965 (comment) Signed-off-by: Manfred Touron <94029+moul@users.noreply.github.com> Co-authored-by: Miloš Živković <milos@zmilos.com>
Doozers
pushed a commit
to Doozers/gno
that referenced
this issue
Aug 31, 2023
This PR introduces a new `gno lint` subcommand, currently focused on checking for the presence of a `gno.mod` file in a package, and it's linked with the CI. In the future, we plan to expand `gno lint` to support additional checks, enhancing its utility for developers and CI integration. Addresses gnolang#850 Addresses gnolang#927 Related with gnolang#965 (comment) Signed-off-by: Manfred Touron <94029+moul@users.noreply.github.com> Co-authored-by: Miloš Živković <milos@zmilos.com>
|
Type checking PR in progress: #1730 |
|
cc @notJoon |
|
Although it's not revive, I'm continuing to create a lint tool based on gnolangci-lint to support most of linting rules. Recently I've been implementing gno-specific rules and other linting functionalities, like auto fix. So, in my personal opinion, I think it might be good to move this entirely to the gno side and then integrate with previous tools. What do you think about this? |
|
If I'm understanding correctly, you're suggesting migrating this linter to the gnolang org? |
@zivkovicmilos |
zivkovicmilos
added
the
help wanted
|
Makes sense as long as it helps Gno builders. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Kick-starting off this issue off of this discussion. A linter is definitely something we'll want, adding some more checks on top of the kind already done by go linters such as revive.
While I don't necessarily agree about the related discussion, I think we can start collecting ideas about what should be added to a future linter.
One first idea, for the current state of things, is that of not having a top-level variable declaration for a map as it is not persistent.
The text was updated successfully, but these errors were encountered: