Little announcement: thanks for anyone showing interest in skott! Just for your own information, this article was not recently updated to include all the latest features that skott has, but it still remains a good introduction to the spirit of the project. Feel free to check the GitHub repository to see the latest CLI/API versions!
Hello everyone, hope you're doing well!
Today I'm very pleased to share a fun project I have been working on for several months now: skott.
skott is a tool that generates a graph of dependencies from your JavaScript/TypeScript/Node.js projects (including TSX/JSX and ES6/CommonJS modules!) and helps you discover circular dependencies, cost imports, file sizes, and many more 💥
Node.js builtin and/or npm third-party dependencies can also be configured to be added in the graph. The main goal is to reproduce the architecture of your application at the file level.
Installation and use
$ npm install skott
skott provides an API to traverse the project graph, deeply search for circular dependencies, find parents or children for a given set of nodes, etc.
Here is a quick overview of the API:
import skott from "skott";
const {
getStructure,
findCircularDependencies,
findParentsOf,
findLeaves
} = await skott({
/**
* The entrypoint of the project. Must be either a CommonJS or ES6 module.
* For now, TypeScript files are not supported as entrypoints.
*/
entrypoint: "dist/index.js",
/**
* Define the max depth of for circular dependencies search. This can be useful
* for performance purposes. This defaults to POSITIVE_INFINITY.
*/
circularMaxDepth: 5,
/**
* This defines whether the base directory of the entrypoint must be included
* in all the relatives file paths.
* For the specified `dist/index.js` above, it would consider the root path
* to be `./` consequently `dist/` would never appear in any file paths.
*/
includeBaseDir: false
});
skott can also be used through the CLI.
Web Visualization
Using the webapp display mode skott --displayMode=webapp, skott generates the graph and then automatically opens an interactive web application in which you can visualize the graph more precisely.
As shown above, we can see all the nodes created from files of your project, and edges are simply representing the links between files of your project. Circular dependencies, third-party dependencies and built-in dependencies can be displayed on demand to adapt the amount of information displayed at once.
Console Visualization
Sometimes, you don't want to open a web interface to check what you want. For that, you can use other display mode that will render an UI in the console. Here is a quick preview of the graph generated for the fastify library:
We can also decide to track more dependencies, for example the npm third-party dependencies (by providing the "--trackThirdPartyDependencies" option)
Node.js builtin dependencies can also be tracked by providing the "--trackBuiltinDependencies" option.
File tree display
Different modes of display are available from the CLI, including file-tree which reconstructs a directory of files from the graph which is far more concise:
Static file generation
In addition to various display modes from the CLI, Skott is also able to create static files reflecting your project graph, including .json, .svg, .md. (using mermaid), and .png.
Here is an example creating a static file from skott itself:
$ skott dist/index.js --staticFile=svg
For medium to big size projects, you'll probably want to use the webapp display mode! 🫣
Circular dependencies
skott also helps finding out circular dependencies very efficiently in the project, you can even provide a max depth search to avoid deep searches that could be costly.
If you're not sure to see why circular dependencies can be problematic, I created a section Why you should care about circular dependencies and dead code in the root documentation of skott
Some options can also be provided to the CLI to configure the exit code that will be used when circular dependencies are met (defaults to "1" meaning error exit).
Skott is fast
We can easily compare skott with madge because skott already covers most of the features madge exposes for a Node.js project.
I did some benchmarks about the computing time required to build a set of graphs from popular libraries for both skott and madge and here are the results:
Webpack (+560 files)
webpack is a static module bundler for modern JavaScript applications.
Webpack is probably one of the heaviest open-source Node.js project I know. So let's do a benchmark!
- using skott takes 503ms
- using madge takes 2.5 seconds
N.B: the difference of files between skott and madge is only because of .json files that are ignored by skott in the graph (as well as other files such as binaries).
Knex.js (+6O files)
knex.js A SQL query builder that is flexible, portable, and fun to use!
using skott takes 60ms
using madge takes 450ms
For building the entire graph of knex.js with even more metadata, skott is 7.5 times faster!
Fastify.js (30 files)
fastify.js is a fast and low overhead web framework, for Node.js
- using skott takes 50ms
- using madge takes 350ms
In this case, skott is 7 times faster than madge.
Skott is extensible
skott aims to offer features that could be extended to any language, given that specific parsers can be implemented along the way. I started from only JavaScript, incrementally brought TypeScript and TSX/JSX support along the way. Why not bringing other languages around the table?
Stay tuned
Many more features will be implemented (skott does not yet have a major version released) to help you easily discover and demystify what's going on under the hood of your Node.js project! I'm also thinking about developing a Web Application that will help you visualize graphs and every metadata related to each file (number of imports, file size, unused imports, etc).
Sharing journey of building an open-source library
I'll also start a series about the journey of building skott, which notably includes:
- [OUT] What it takes to build a static analysis tool (parsers, ast, etc)
- How to make all of that fully testable by using dependency injection and Test-Driven Development!
Don't hesitate to bring stars ⭐️, issues, feedbacks directly on GitHub here as it will allow me to drive the project where it will bring the most value for each developer.
Thanks for reading this far, wish everyone a wonderful day ☀️
Top comments (15)
WOW!! Finally a tool that will help us reduce technical debt and give us some metrics to take strategic decision on the codebase.
Thanks @antoinecoulon!
I will follow your interesting series about the journey of building skott.
Thanks a lot for you feedback @ild0tt0re I appreciate it!
Tomorrow will be the first episode of the series dedicated to the journey, happy to know that you'll be following that =)
Looking forward to chat with you!
Great one! What's the difference with dependency cruiser?
Thanks @frolovdev :)
dependency-cruiseris a great tool, it's true that according to this introduction they look alike as they both enable graph visualization from JavaScript/TypeScript projects.Nevertheless the main objective of
Skottis not really to act only as a dependencies visualizer but instead its goal is to expose API primitives on top of the generated graph. This would allow the graph to be used to perform graph inspection (cyclic dependencies, unused nodes, dead code), graph diffing, but also creating incremental tasks orchestrator tools, etc.Thank you for the clarification, looks sick!
Hey Antoine Coulon, This is so amazing! We are so grateful to you! It works like charm!
Hey @darshan1212, thank you very much for your feedback, appreciate it a lot!
Feel free to open issues for either bugs or features if you have ideas in mind :)
Looks like a promising tool!
Thanks for the feedback @pdoy38!
Certainly a cool tool but what is the actual benefit of using something like this other than visualization? How can I use this to improve my project?
Thanks for the feedback @wadecodez :)
Visualization is just a support to draw the dependency graph of the project (you can start the project in headless mode), but the analysis aims to be wider than just for visualization purposes such as detecting cyclic imports, tracking unused imports/exports (not yet implemented), enforcing imports boundaries (not yet implemented) etc. The goal in the long run is not even the visualization as the primary purpose, but allowing a quick feedback about dead code, misconceptions, architecture smells for any project and for any programming language (only a JavaScript parser is implemented but Python, Go etc could be introspected the same way).
By the way, this is just the 0.2.* version so no a major release yet, I would be happy to hear any suggestion or feature that would be valuable for you.
EDIT:
Also another topic which is not covered up in this article is simply the fact of traversing and using the directed graphs generated by skott (find leaves, find deeply all parents/children of a given nodes, etc). For instance it could fundamentally be used by tools aiming to process incremental/affected tasks.
It would be cool if the tool could automatically remove cyclic dependencies and/or optimize imports.
Hi, thanks for creating this awesome tool. I am, however, not super clear on how to implement this at work. We have a typescript/react mono-repo setup which uses Rush. I am trying to follow the documentation on the Github repo but it's not super clear to me how this works. What are we supposed to do with the Javascript API you've shown here and on your repo? Is this just for example? To show what is exposed? Or, are we supposed to embed this in the app somehow? The only thing I've been able to grok at this point is installing skott and running it from the node_modules .bin directory which spits out a gigantic graph. So I know it is working. Is that the idea? Idk, I'm totally confused.
What’s that font? 😍
@matiascarpintini Cascadia Code PL :)