Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
  • ¿Algo no está bien?
#9,182 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
55/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
typescript
Área
tooling

Línea de trabajo

Lee src/components/build-common/eslint.config.mjs e inspecciona la configuración existente relacionada con los imports y la configuración de lint del paquete. Determina cómo debe cubrir la regla compartida src/Standalone y src/components, incluidos los archivos de prueba y los archivos *Resources.ts generados. Se considera terminado cuando la regla está habilitada, las infracciones existentes se han corregido o documentado como supresiones deliberadas, y CI rechaza nuevas infracciones.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.
Lenguaje dominante
Sin datos de lenguaje
Estrellas
458
Forks
92
Merge medio
1 d 2 h
PR fusionados (30 d)
1

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de microsoft/AzureStorageExplorer

Todos los issues de microsoft/AzureStorageExplorer

Issues similares

Más issues de DevTools

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.