search

uhyo / eslint-plugin-import-access

https://www.npmjs.com/package/eslint-plugin-import-access
MIT License
355 stars 9 forks source link

Default exports; A rule for entire files #2

Closed A-Shleifman closed 1 year ago

A-Shleifman commented 2 years ago

Thank you for this amazing plugin @uhyo!

I have two questions:

  1. Is there a way to make this rule work for default exports? Doesn't seem to work at the moment.
  2. Is there a way to apply @package rule to an entire file?
uhyo commented 2 years ago

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 commented 1 year ago

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:

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 commented 1 year ago

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 commented 1 year ago

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

Added support for "Path Tags"

uhyo commented 1 year ago

@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!

A-Shleifman commented 1 year ago

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