Default exports; A rule for entire files about eslint-plugin-import-access

[A-Shleifman]

@uhyo Makes sense! I'll publish my version then in case anyone is interested in the Strict Mode. Renamed @package to @scope. Thank you! :)

[uhyo]

Thank you for your suggestion! Unfortunately neither is possible currently.

If this rule doesn't work for default exports, it is a bug. I haven't tested it with default exports 😨

The entire file rule is definitely great to have, but I haven't figured out a nice way of specifying file-level rules.

I'll try to work on them 🙂

[A-Shleifman]

Hi @uhyo! We decided to work on this issue at the same time 😅 A week ago I finally had some time to dive into this... As I didn't have experience writing ESLint/TS plugins before I decided to start from scratch to have a full understanding of what is going on. Obviously, it is heavily inspired by your implementation.

That's what I have at the moment

You can check out the README to see how it works. What do you think? Would you like to merge it into your repo? It's ok if you don't 😄 The actual implementation fits into 4 files.

Missing options compared to your version:

• indexLoophole - it's the default behaviour when in Strict Mode
• filenameLoophole - can it be solved by colocating related files in the same directory?

I don't like that my version requires parserOptions.project to be configured, but I couldn't make eslint work without this setting with your version as well 🤷‍♂️

[A-Shleifman]

I kept the same package name in case you want to merge, but I've changed the rule name as ESLint recommends to start disallow rules with no-

[A-Shleifman]

Looks like there's no way around parserOptions.project.

Added support for "Path Tags"

[uhyo]

@A-Shleifman First of all, sorry for my slow work 🥺 and yes, this kind of plugins need parserOptions.project, so as mine. Otherwise we have to perform module resolution by ourselves without help of TypeScript's built-in resolver.

Actually your implementation is impressing; the idea of Strict Mode and Path Tags are interesting.

However, I think it is a little difficult to merge your implementation into mine for two reasons. You implemented the plugin from scratch so it is hard to fusion the two implementations. Also, your @package semantics has departed a bit too far from JSDon's known semantics, and that's not how I would like my plugin to look like.

So I think you can give your own name to your plugin and go on. Thank you for sharing!