Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Custom packageFilter (and possibly extensions) #48

Closed
brettz9 opened this issue Jun 9, 2020 · 0 comments
Closed

Custom packageFilter (and possibly extensions) #48

brettz9 opened this issue Jun 9, 2020 · 0 comments

Comments

@brettz9
Copy link
Contributor

brettz9 commented Jun 9, 2020

Hi,

I'm not sure this fits with your goals, particularly if you are aimed only at use with eslint-plugin-import, but your project appears to be a good fit for my project es-file-traverse. My project builds a list of file names that are found when traversing an entry file or files--whether through CJS require or ESM import, and whether through Node's algorithm or, through your project's help, through TypeScript's traversal algorithm.

The project's main use case is to list files to feed to eslint (so one can, for example, lint only those dependency files actually in use in one's project, e.g., for catching bad practices or vulnerabilities in one's dependencies). However, in linting TypeScript for such concerns, it is of less interest to follow a chain of TypeScript imports into 3rd party TypeScript declaration files than to follow say the TS source normally, but to prefer a JavaScript file over a declaration file.

So, I think it may be nice to be able to have a custom packageFilter and maybe a custom extensions, such that, for example, the module field could be given precedence over types and typings when .d.ts is the extension (or at least supply the extensions to the proposed custom packageFilter option callback). (It seems per microsoft/TypeScript#21423 that there are at least some projects using source in the wild to point to a main TS source file, so this might be preferable to even JS as it should in theory keep us in the TS source chain if a package bundles its source--more reliably than looking into tsconfig.json with its multiple entries could do.)

(Please note that I'm pretty new to TS though, so am hopefully not too far off in some of my ideas.)

If you'd be open to such an option, I can see about preparing a PR.

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

2 participants