NPM workspaces considered third party packages

[PeteBBC]

Hi,

It seems like if you are using npm workspaces you can't build a graph beyond/through those package boundaries.

I wonder if it is possible to either:

1. deeply graph third party packages, or
2. distinguish npm workspace packages from third party packages.

Thanks for all your effort on this project, it looks great!

[antoine-coulon]

Hello @PeteBBC,

Thanks for the kind words!

That is correct, there is currently no direct support for npm/pnpm/yarn workspaces or even monorepo tools (Nx/Lerna/Rush/Turborepo, etc). I initially stated that this could be supported using the API by having custom resolvers which are nothing but plugins extending the core module resolution, you can see an example here of a custom resolver I wrote for Rush.js monorepo tool. By hooking into the module resolution step before the default resolver (or completely getting rid of it), you'll be able to distinguish workspace dependencies from third-party dependencies by using the workspaceConfiguration provided through the resolve function arguments of the resolver.

In summary what I'd suggest for now is:

1. write a tiny custom npm workspace resolver (this could be generic to any workspace manager though as this will be the same principles applied) and plug it into skott together but before the default resolver dependencyResolvers: [new YourResolver(), new EcmaScriptDependencyResolver()]. You can keep the EcmaScriptDependencyResolver if you still want other modules, including third-party packages to be collected (and builtin modules), otherwise just keep the custom resolver. Basically this resolver would use the workspaceConfiguration dependencies and distinguish workspace deps adding custom properties to graph nodes bodies (in the same way as I did for Rush) if you want to use the graph data structure afterwards
2. skott can then build the whole graph, the only problem is that the UI (or any other visualization mode) won't be customizable in such way that npm workspace deps can be displayed nor highlighted if they are added through custom properties. It's a thing that I'll be working on while revamping the webapp feat: revamp skott webapp #72. So what I'd suggest is to either completely discard them using your custom resolver or only build a graph of workspace dependencies (and nothing else) and separately a graph of module dependencies (JS/TS modules + third-party / builtin)

On my own I'll think about a way of displaying/highlighting in a custom way a set of dependencies/nodes so that once they're collected through custom resolvers they can be visually distinguished.

Sorry to not have any other better solution for now, I'll be able to follow the issue and bring improvements but with a low reaction time as I'm currently on vacation, but once I have more time I'll for sure spend some time thinking about it so feel free to share other needs :-)