You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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!
The text was updated successfully, but these errors were encountered:
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 projectes-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 customextensions
, such that, for example, themodule
field could be given precedence overtypes
andtypings
when.d.ts
is the extension (or at least supply the extensions to the proposed custompackageFilter
option callback). (It seems per microsoft/TypeScript#21423 that there are at least some projects usingsource
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 intotsconfig.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!
The text was updated successfully, but these errors were encountered: