All-in-one devtool to automatically analyze, search and visualize project modules and dependencies from JavaScript, TypeScript (JSX/TSX) and Node.js (ES6, CommonJS)
MIT License
669
stars
25
forks
source link
Allow Skott to perform a global analysis without specifying an entrypoint #5
Following #2 #4 which were both resolved in #3, the only missing piece to use Skott in most cases is the ability to perform a global analysis without specifying any entrypoint.
The reason for that is that some projects such as Next.js use file-system based routing which implicitly create links between files (without using any import/export statement, thing that Skott relies on to create the graph).
Consequently the goal is to be able to deeply collect a specific set of independent files (basically .ts, .js, .tsx, .jsx) which are not linked by any import/export statement. This would allow Skott to produce sub graphs and unify them as a single project graph.
In the context of monorepo/workspaces, this could also be useful.
Given two independent libs that are evolving independently (without any dependency toward each other):
Following #2 #4 which were both resolved in #3, the only missing piece to use Skott in most cases is the ability to perform a global analysis without specifying any entrypoint.
The reason for that is that some projects such as Next.js use file-system based routing which implicitly create links between files (without using any import/export statement, thing that Skott relies on to create the graph).
Consequently the goal is to be able to deeply collect a specific set of independent files (basically .ts, .js, .tsx, .jsx) which are not linked by any import/export statement. This would allow Skott to produce sub graphs and unify them as a single project graph.
In the context of monorepo/workspaces, this could also be useful. Given two independent libs that are evolving independently (without any dependency toward each other):
The resulting graph could be: