Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

Linters for Envbuilder aren't catching some common concerns that we have

Offen
  • Stimmt etwas nicht?
#399 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
4/5
Geschätzter Aufwand
3-5 Tage
Anfängerfreundlichkeit
35/100
Issue-Typ
Refactoring
Klarheit
Größtenteils klar
Aktivitätsstatus
Veraltet
Tech-Stack
go
Bereich
testing, tooling

Rechercherichtung

Beginne mit der Überprüfung der Linting-Konfiguration und vergleiche sie mit der Konfiguration von coder/coder. Führe anschließend den aktuellen Linter gegen envbuilder.go, devcontainer/devcontainer.go und devcontainer/script.go aus. Füge die vereinbarten Regeln für die Dokumentation exportierter Elemente und parallelisierbare Tests hinzu, behebe die daraus resultierenden Verstöße und stelle sicher, dass die Lint- und Testbefehle des Projekts erfolgreich ausgeführt werden.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

ci 
          Suggestion: It's best practice for exported functions to have documentation (`// EnvWithBuildSecretPrefix ...`). It's part of the original Go linter (https://pkg.go.dev/github.com/golang/lint) and [CodeReviewComments](https://go.dev/wiki/CodeReviewComments#doc-comments)/[Effective Go](https://go.dev/doc/effective_go#commentary), so a bit surprising that it's not caught.

❯ golint ./...
envbuilder.go:43:2: a blank import should be only in a main or test package, or have a comment justifying it
devcontainer/devcontainer.go:34:6: exported type Spec should have comment or be unexported
devcontainer/devcontainer.go:50:6: exported type LifecycleScripts should have comment or be unexported
devcontainer/devcontainer.go:57:6: exported type BuildSpec should have comment or be unexported
devcontainer/devcontainer.go:78:1: exported function SubstituteVars should have comment or be unexported
devcontainer/script.go:16:6: exported type LifecycleScript should have comment or be unexported
devcontainer/script.go:21:1: exported method LifecycleScript.IsEmpty should have comment or be unexported

It seems golint is marked deprecated in golangci-lint though, so I guess the alternative linters aren't enforcing this rule. 😔 I always found it slightly annoying but ultimately worth the annoyance 😄.

Originally posted by @mafredri in https://github.com/coder/envbuilder/pull/391#discussion_r1818991909

There seem to be some linting rules that we'd value here. Two of them are:

  • Tests should run in parallel when they can
  • Exported functions should be documented

There may be others. It would be worth checking coder/coder's linting config to see what else we're missing. We should add the linters we deem important and ensure the project conforms to them.

Vorherrschende Sprache
Go
Sterne
302
Forks
65
Ø Merge
1 T. 12 Std.
Gemergte PRs (30 T.)
3

Entwicklungsumgebung

In Codespaces öffnen

Startet den Dev-Container des Projekts im Browser, mit Ihrem eigenen GitHub-Konto.

  • Kein Dockerfile und keine Docker-Compose-Datei
  • Keine Pull-Request-Vorlage
  • Kein Beitragsleitfaden

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus coder/envbuilder

Alle Issues in coder/envbuilder

Ähnliche Issues

Weitere Issues zu Go

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.