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.