provde option to ignore barrel files
Opened this issue · 7 comments
Summary
i want to exclude barrel files from tree
Details
What are barrel files:
https://dev.to/tassiofront/barrel-files-and-why-you-should-stop-using-them-now-bc4
Standard questions
Please answer these questions to help us investigate your issue more quickly:
Question | Answer |
---|---|
Would you consider contributing a PR? |
Hello @andriyor, thanks for opening that issue.
I'll think a little bit about how we could come up with that kind of feature without impacting skott's genericity when dealing with files, and I'll come back at you.
Currently in most cases i use typescript, so i decided to create small library based on ts-morph which uses ts API under the hood
https://github.com/andriyor/ts-tree
Also i made CLI tool for it https://github.com/andriyor/ts-tree-cli and web app https://github.com/andriyor/coverage-tree-next
With this tools i can generate such test coverage report
Such a nice library you have there @andriyor, great job!
To be honest excluding barrel files is such a specific use case in the context of TypeScript so I'm less likely to land that in skott's core. However if the need arises of doing such specific things (requiring AST introspection), I might be able to inject traversed AST information into a specific API function that keeps or not nodes so that people could decide to say given this AST node should it make it to the final graph or not.
The addition would be something like:
skott({
onNode: (context, [keep, exclude]) => {
if(isBarrelFile(context.nodeAST)) return exclude();
keep();
}
})
Where isBarrelFile
would be living outside of skott, either coming from utility exposed by skott or whatever library that can deal with TypeScript AST nodes.
What do you think?
Barrel files is not only TypeScript feature https://uglow.medium.com/burn-the-barrel-c282578f21b6
Yeah it would be niche to provide API to make custom import handling
Also you can take a look on recently published package https://github.com/thepassle/module-graph which have pretty nice api
Yes I know barrel files are not specific to TypeScript I was referring to JS/TS context in general, what I wanted to say is that this is such a specific feature around the ECMAScript ecosystem but ideally I would make these specific things external to the core itself and provide specific adapters/plugins to make it work, as in the future I would like to expand skott to other ecosystem such as Python or Go.
Yeah it would be niche to provide API to make custom import handling
Then let's make it happen, I'll provide an API that allows each node to be checked and discarded/kept before internal logic kicks in.
Also you can take a look on recently published package https://github.com/thepassle/module-graph which have pretty nice api
Thanks for the reference, indeed skott's API exposes way more graphs primitives but one thing lacking is the ability to deal with the AST node upfront (import/export etc declarations). With the custom dependency resolver API we already have a way of handling module declarations
but we don't really know from where they come from (only the identifier is kept so it's higher level) hence we need a lower-level API that operates on the AST so I'll get that implemented.
Regarding your use case of ignoring barrel files, what do you exactly have in mind after getting rid of them? If we just ignore them, the problem is that the final graph will contains holes as barrel files are often nodes linking other nodes so just getting rid of them will create orphans and sub graphs with no dependencies between each other.
One solution would be to change all the nodes depending on the barrel files to make them depend on nodes the barrel was depending on. But in that case, it makes skott creating a whole another graph that does not contain any barrel but still preserve the relationships between nodes. This could even be useful to create a tool to transition from a codebase containing barrel files to another one without any barrel.
By ignoring barrel files, I mean the solution that you already mentioned. Just to remove the noise of redundant nodes