Skip to content

Proposal: Add gopherjsvet tool #1219

Open
@flimzy

Description

@flimzy

Background

I just built a trivial linter during a recently 2-hour livestream on my YouTube channel. During my next livestream, I intend to start building a real/useful linter. And I had the idea of creating one for gopherjs.

So I'm opening this issue to get feedback and to solicit rule ideas to include.

Proposal

Create a new repo, github.com/gopherjs/gopherjsvet, which will contain a linter that can be embedded into golangci-lint, as well as compatible with go vet, and usable as a standalone binary.

Linter rules

My proposed linter rules (pending feasability, of course) so far are listed here. I'm soliciting suggestions for others. They should be issues that apply only to GopherJS code, as any other issues should go in a general-purpose linter. Most of these come from JavaScript Tips and Gotchas

  • Do not use items or fields of type js.Object directly
  • *js.Object must always be a pointer
  • A struct that embeds a *js.Object must always be a pointer.
  • Ensure that whenever js tags are present, a *js.Object field is embedded as the first struct field.
  • Ensure that struct literals for struct types that embed *js.Object do not also initialize other fields.
  • Ensure no non-scalar types in structs that embed *js.Object.
  • Complain about trying to json.Unmarshal into mixed Go/JS data structures.
  • Complain about blocking function calls in callbacks (not sure how easy this is actually to detect conclusively, but I'm sure we can get somewhere)
  • Ensure that proper build tags are set on any files that import github.com/gopherjs/gopherjs/js and syscall/js
  • Warn about use of the net/http package
  • (Optionally) warn about the use of encoding/json package when only unmarshaling.

Other Considerations

My immediate interest in this is mostly educational. So whether this proposal is accepted or not, I do intend to go forward (I just may do so in a private project, rather than one hosted under the gopherjs project).

Beyond that immediate goal, if this proves to be both feasable and of general interest, once the linter reaches a certain level of usefulness/maturity (criteria TBD), I would like to:

  • Publish pre-compiled binaries with goreleaser for common OSes (Linux, Mac, Windows probably)
  • Submit a PR to golangci-lint to include this linter

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions