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

Add lint rule enforcing type imports in a separate block before other imports

Offen
  • Stimmt etwas nicht?
#9,182 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
4/5
Geschätzter Aufwand
3-5 Tage
Anfängerfreundlichkeit
55/100
Issue-Typ
Feature
Klarheit
Größtenteils klar
Aktivitätsstatus
Aktiv
Tech-Stack
typescript
Bereich
tooling

Rechercherichtung

Lies src/components/build-common/eslint.config.mjs und prüfe die bestehende importbezogene Konfiguration sowie das Lint-Setup des Pakets. Ermittle, wie die gemeinsame Regel src/Standalone und src/components abdecken soll, einschließlich Testdateien und generierter *Resources.ts-Dateien. Als abgeschlossen gilt die Aufgabe, wenn die Regel aktiviert ist, bestehende Verstöße behoben oder als absichtliche Unterdrückungen dokumentiert sind und CI neue Verstöße ablehnt.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

Problem

Type imports are inconsistently placed throughout the codebase. In some files they are interleaved with value imports; in others they appear below them. There is currently no automated enforcement, so the convention is only applied when a reviewer happens to notice it.

This surfaced during review of !777789 - Fix SDK job type imports in blob/table extensions, where the reviewer asked for type imports to be moved into a separate block above other imports. Investigation showed the placement in question was pre-existing on main, not introduced by that PR -- the change only renamed identifiers on those lines. That makes it a codebase-wide convention gap rather than a defect in any single change, and it means the same review comment will keep recurring on unrelated PRs until it is enforced automatically.

Proposal

Add an ESLint rule to src/components/build-common/eslint.config.mjs enforcing that:

  1. Type-only imports are grouped into their own contiguous block.
  2. That block appears before all value imports.

Likely implementation, to be confirmed by whoever picks this up:

  • @typescript-eslint/consistent-type-imports to ensure type-only imports actually use import type syntax, so they are statically distinguishable.
  • import/order (or the equivalent already in use) with an explicit type group ordered first, to enforce block placement and separation.

Considerations

  • Fleet-wide churn. Enabling this with autofix will touch a large number of files across src/Standalone and every package under src/components. The rollout should be a dedicated PR separate from any feature or bugfix work, so the diff stays reviewable and does not collide with in-flight branches.
  • Sequencing. Several component PRs are in flight right now. This should land during a quiet window, or be staged per-package, to avoid manufacturing merge conflicts across active branches.
  • Version bumps. Any src/components/* package touched by the autofix requires a version bump per repo rules. If the rollout is staged per-package, each stage carries its own bump.
  • Confirm whether the rule should apply to test files and to generated files. Generated *Resources.ts files under src/Standalone/app/resources/ are rewritten by the gulp resource generator on every build, so any lint fix applied to them would be reverted on the next build. Those should almost certainly be excluded, or the generator template updated instead.

Acceptance criteria

  • Lint rule is enabled in the shared ESLint config.
  • Existing violations are fixed, or explicitly and deliberately suppressed with a documented rationale.
  • CI fails on new violations.
Vorherrschende Sprache
Keine Sprachdaten
Sterne
458
Forks
92
Keine gemergten PRs in 30 T.

Entwicklungsumgebung

Dieses Projekt bietet weder Dev-Container noch Dockerfile noch Beitragsleitfaden – die Einrichtung liegt bei Ihnen. Beginnen Sie mit der README; die allgemeinen Schritte stehen in unserem Leitfaden für den ersten Beitrag.

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 microsoft/AzureStorageExplorer

Alle Issues in microsoft/AzureStorageExplorer

Ähnliche Issues

Weitere Issues zu DevTools

Neue Issues direkt in Ihr Postfach

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