Closed mozisan closed 1 year ago
ありがとうございます! 基本的には import
できないものを export { } from ...
できるのはおかしいので、防げた方が望ましいと思います。これで壊れるコードもそこまで無さそうなのでオプトインにする必要も無さそうに思います。
ただ、考慮すべきパターンは結構ありそうです。
export {
/**
* @private
*/
foo, // ←これはできるのか?
} from "..."
export * from "..." // これは全部チェックする必要がある
こちらこそありがとうございます!!!!
export { /** * @private */ foo, // ←これはできるのか? } from "..."
これはTypeScript側の#47293が関連する点ですね。
手元のプロジェクトでこの記述が期待通りに動くか確認してみましたが、この差分が含まれる>=4.6
のTypeScriptであれば動いていそうでした👍
export * from "..." // これは全部チェックする必要がある
これは結構ややこしそうですね🤒 このとき同時に以下のコードも全部チェックした方が良さそうでしょうか?
import * as Foo from "..."; // Foo.xで参照できるすべてがインポート可能であることをチェックする
この差分が含まれる>=4.6のTypeScriptであれば動いていそうでした👍
それは朗報ですね。 🙂
import * as Foo
のパターンも、抜け穴を全部防ぐという意味ではチェックすべきですね。 :sob:
ただ、全部一度にやる必要はないかと思います。協力いただいている立場なので、興味あるところをやっていただければと思います。 :pray:
import * as Foo
のパターンも、抜け穴を全部防ぐという意味ではチェックすべきですね。 😭 ただ、全部一度にやる必要はないかと思います。協力いただいている立場なので、興味あるところをやっていただければと思います。 🙏
承知しました!
import * as Foo from "..."
もexport * from "..."
も結構また別の処理を追加しないといけなさそうな感じがするので、一旦そこは別PRで対応というように切り分けられたらと思います :pray:
なので先にこのPRだけ提出という形にさせていただければと思うので、何か修正した方が良さそうな点などあればまたコメントいただければ修正します :bow:
連日でPRを投げて騒がしくしてしまいすみません :sob:
現時点で以下のような記述ができますが、
「あるファイルからインポートできないものは再エクスポートもできない」という挙動の方がこのプラグインでガチガチに縛ろうとしたときには価値を発揮するかなと個人的には思ったのですが、いかがでしょうか・・・?
また、もしこの変更を導入する場合にはプラグインのオプションを追加してユーザーがオプトインできる形の方がいいのかも、ということもちょっと思ってはいますが、その辺ももしご意見あれば頂けると幸いでございます :pray: (別の観点として、プラグイン名としては
import-access
の制御を担っており、こういったexport
宣言についてのチェックは本来のスコープ外のようにも思えるので、その意味でもオプトインの方が好ましいのかなと思ったり)