Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

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

未关闭
  • 哪里不对？
#9,182 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

还没有人认领这个 Issue。

评估

难度
4/5
预计耗时
3-5 天
新手友好度
55/100
Issue 类型
功能
描述清晰度
基本清楚
活跃度
活跃
技术栈
typescript
领域
tooling

调研方向

阅读 src/components/build-common/eslint.config.mjs，检查现有的 import 相关配置和 package lint 设置。确定共享规则应如何覆盖 src/Standalone 和 src/components，包括测试文件和生成的 *Resources.ts 文件。规则已启用、现有违规已修复或记录为有意的抑制，并且 CI 会拒绝新的违规时，即表示完成。

由索引模型根据 Issue 内容生成。

描述

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.
主要语言
没有语言数据
星标
458
派生
92
平均合并
1 天 2 小时
30 天内合并 PR
1

环境准备

这个项目没有提供开发容器、Dockerfile 或贡献指南，环境需要你自己搭建：先看它的 README，通用步骤见我们的新手贡献指南。

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

microsoft/AzureStorageExplorer 的其他 Issue

查看 microsoft/AzureStorageExplorer 的全部 Issue

相似的 Issue

更多 DevTools Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。