import-js/eslint-plugin-import

expose semi-core modules via resolvers

Open

#479 opened on 2016年8月8日

GitHub で見る
 (6 comments) (7 reactions) (0 assignees)JavaScript (4,946 stars) (1,540 forks)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
Issue 種別
feature
難度新しい貢献者にとっての実装難度です。1 は非常に小さな変更、5 は専門的な作業です。
4
推定時間経験ある貢献者が調査、実装、テスト、pull request 準備にかけるおおよその時間範囲です。
3-5 days
活動状況Issue が今どれだけ取り組みやすいかを示します。新しい、活発、古い、ブロック中、またはメンテナー入力待ちなどです。
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.