Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

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

Ouverte
  • Quelque chose ne va pas ?
#9,182 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Personne n'a encore pris cette issue.

Évaluation

Difficulté
4/5
Temps estimé
3-5 jours
Accessibilité débutants
55/100
Type d'issue
Fonctionnalité
Clarté
Plutôt claire
Activité
Active
Stack technique
typescript
Domaine
tooling

Piste de recherche

Lisez src/components/build-common/eslint.config.mjs et examinez la configuration existante liée aux imports ainsi que la configuration de lint du package. Déterminez comment la règle partagée doit couvrir src/Standalone et src/components, y compris les fichiers de test et les fichiers *Resources.ts générés. C’est terminé lorsque la règle est activée, que les violations existantes sont corrigées ou documentées comme des suppressions délibérées, et que CI rejette les nouvelles violations.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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.
Langage dominant
Aucune donnée de langage
Étoiles
458
Forks
92
Merge moyen
1 j 2 h
PR mergées (30 j)
1

Préparer son environnement

Ce projet ne fournit ni conteneur de développement, ni Dockerfile, ni guide de contribution : l'installation est à votre charge. Commencez par son README, et consultez notre guide de la première contribution pour les étapes générales.

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de microsoft/AzureStorageExplorer

Toutes les issues de microsoft/AzureStorageExplorer

Issues similaires

Plus d'issues DevTools

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.