import-js/eslint-plugin-import

expose semi-core modules via resolvers

Open

#479 创建于 2016年8月8日

在 GitHub 查看
 (6 评论) (7 反应) (0 负责人)JavaScript (4,946 star) (1,540 fork)batch import
enhancementhelp wantedresolversemver-major

描述

https://github.com/clayne11/eslint-import-resolver-meteor/issues/11

TL;DR: semi-magic modules (in this case, meteor/*) that exist on disk (and thus can be linted) but are baked into the environment (and thus, are not explicitly dependencies) ideally should not blow up no-extraneous-dependencies.

Hand-wavy possible solution: allow resolvers to define import types somehow. (maybe move the importType functionality down into the resolver spec?)

Or could keep the existing behavior when/if chosen resolver does not explicitly provide the designation.

贡献者指南

技术栈
javascriptnodejs
领域
toolingdeveloper experience
议题类型
feature
难度面向新贡献者的预计实现难度，1 表示很小改动，5 表示专家级工作。
4
预计时间有经验贡献者完成调查、实现、测试并准备 pull request 的粗略时间范围。
3-5 days
活动状态议题当前的可参与程度：新鲜、活跃、陈旧、阻塞或等待维护者输入。
stale
清晰度议题是否清楚说明期望改动、验收标准和下一步。
needs investigation
前置要求
ESLint plugin architectureimport resolutionNode.js module system
新手友好度1-100 的估计分数，表示该议题对首次贡献者的友好程度。
25
研究方向
Investigate the current resolver implementation in eslint plugin import (likely in src/resolvers/). Review the linked issue for context on how meteor/* modules cause false positives for no extraneous dependencies. Propose a design for allowing resolvers to specify import types, possibly by adding a method or metadata to the resolver spec. Consider backwards compatibility and ensure existing resolvers continue to work. Document the approach and get feedback from maintainers.