gabotechs / dep-tree Goto Github PK

Hello Gabriel. I want to let you know that discovering this package on /r/javascript made my day today.

What a terrific (and fast!) tool that I wish I discovered a week ago!

I'm in the middle of trying to write a change detector for a CI/CD pipeline and the functionality I'm looking for is very close to what dep-tree offers.

Was wondering if you would consider adding another command -- similar to render -- that could output the dependency tree to JSON format (or even YAML)?

Feature Request Summary

For example, given the following output from render:

index.tsx
│
├▷../../../../libs/providers/products/products.ts
└▷│../../../../libs/utils/analytics/commonEvents.ts
  ││
  └│▷../../../../libs/providers/_factory.tsx
   ├▷../../../../libs/utils/analytics/constants.ts
   └▷../../../../libs/utils/url.ts

It would be cool to have an option to output something like this to stdout:

{
   /* parent dep, has list of child deps */
   "index.tsx": [
      /* item plain string means no further child deps */
      "../../../../libs/providers/products/products.ts",
      /* object means further child deps follow */
      {
         /* process continues, recursively */
         "../../../../libs/utils/analytics/commonEvents.ts": [
            /* leaf nodes -- no further sub-deps */
            "../../../../libs/providers/_factory.tsx",
            "../../../../libs/utils/analytics/constants.ts",
            "../../../../libs/utils/url.ts"
         ]
      }
   ]
}

(This syntax is just a suggestion, not a requirement)

Suggested Interface

This could either be:

1. A new command (eg dep-tree parse ...)
2. An output/format flag on the existing render command (eg dep-tree render ... --output=json)

If we go with option 2, it could either be:

1. --output=<format> like kubectl
2. --json like Yarn workspace tools

Prior Art

I've evaluated some other options but none of them have the ease-of-operation nor the speed of your package. Here's what I've tried:

@vercel/nft

Node File Trace comes close but:

👎 It has no CLI
👎 It's much slower
👎 It has a strange bug/behaviour where the current working directory changes the output

dependency-cruiser

Dependency Cruiser is very powerful but:

👎 Is much more verbose in output
👎 Harder to use (not as targeted to the exact use-case of dep-tree
👎 Appears unable to cross the package.json boundaries

dependency-tree

Dependency Tree has more of the same issues:

👎 Is slower
👎 Requires more onerous configuration
👎 inherits bugs from the underlying precinct module

The reason I ask this request of you is because your package already has the following advantages:

✅ speed
✅ correctness
✅ appropriateness to my use-case
✅ punches through package boundaries without issue

And would be perfect if I could get a machine-readable output! 😁

Please let me know if this is something you'd consider adding.

Thanks
Bryce

Take for example https://github.com/pyca/cryptography

I tried dep-tree-explorer with the following input:

• GitHub Project: https://github.com/pyca/cryptography
• Entrypoint: src/cryptography/init.py

Hello,

My coworker and I have been working on a project with similar goals & philosophy as dep-tree: https://github.com/dustin/graphex

It analyzes Haskell codebases and produces the graph as JSON. And it provides a CLI to analyze deps (for instance, you can ask why one file depends on another file to debug a tangled graph).

It already supports Looking Glass for visualization, but dep-tree entropy looks like it would be an improvement in many ways.

I'd love to hook it up to dep-tree entropy. But it looks like dep-tree entropy doesn't support just giving it a graph in some standard format? And it instead couples the graph generation with the graph visualization?

If there was some JSON format I could target, I could easily write a graphex graph dep-tree that converts graphex's JSON format to dep-tree's.

(I'd happily do the legwork to make this happen myself btw! If you have any pointers for getting started.)

I love those kind of visualizations.

Do you plan support on Go codebase?
Do you know if it could be somewhat trivial if somebody jumps in your codebase?

The Rust language allows to prefix imported modules with r#, so that if the module is named after a reserver keyword, like async, then it's interpreted as a raw string, and therefore a module name instead of the actual async keyword.

To avoid having dep-tree inside our dependencies, try to deploy it and have a global script associated.
https://github.com/Haimantika/introduction-npm-package to know how to do it.

In WSL2, I don't have a GUI environment or browser, so it fails when trying to show the generated HTML.

I found out I can specify the --no-browser-open flag to bypass this behavior, but it only prints the HTML path in the temp folder because the file is always saved.

Maybe it always should print the HTML path, no matter if the flag is specified or not?

For JS/TS it would be useful to have a boolean flag saying if imports outside the package.json boundaries are allowed or not.

For Python, a boolean flag saying if full imports (import foo) should be taking into account for making the tree. It is common to have a python package called foo and in foo/app/logic.py do a import foo. Does that mean that foo/app/logic.py depend on the whole foo package? right now not, but maybe this should be configurable.

I run the command dep-tree -c .dep-tree.yml but it doesn't work. Prompt me Error: requires at least 1 arg(s), only received 0 What's the key point is I missed?

# .dep-tree.yml
  entrypoints:
    - src/main.js
    - src/renderer.js

the keyword type preceding an import name is not taken into account

I oftenly find myself writing dep-tree ./path when I want to render a file import tree in the terminal, which is incorrect.

I suggest defaulting dep-tree with no arguments to dep-tree render subcommand

I've discovered an issue with resolving modules that use the 'main' field in package.json to specify the entry point.

In my project, I have a structure where the directory "/subFile" contains a "subFile.tsx" file and a package.json file. The package.json file specifies the main field as subFile.tsx.

{
  "main": "subFile.tsx"
}

When I import this module with import subFile from './subFile', the expected behavior is that Node.js and TypeScript will look for a package.json in the subFile directory and use the file specified in the main field.

However, those files don't show up in the dependency graph.

Please consider adding support for resolving the main field in package.json files.

Importing different aliased packages somehow resolves to the same package

First of all, thank you very much for this amazing tool, but in the process of using , I found the ts code which uses alias or path alias, neither the generated dependency tree nor the entropy diagram, there are none of these alias dependent resource files, such as:
// src/index.ts
import { environment } from '@Environment';
import '@/a/b/c';

// tsconfig.json
"paths": {
"@/": ["./src/"],
"@Environment": ["./src/environments/environments.ts"
].

the dependencies of src/index.ts does not have the environment or the @/a/b/c

Hello. I really like the idea!

Is it possible to build graph using directory path? You will need to iterate over all files and all directories in specified dir, I guess. Would be really cool to analyze the whole repository and check condition of the whole code specifing only directory

We can already generate doxygen to generate dependency graph. But, 3d interactive graph looks cool.

The loading spinner often stucks in this position:

⠋ Loading graph... (0 it/hr) [0s] 

It should be more fluent

The imports field in package.json is ignored.

Example:

"imports": {
    "#Assets/*": "./src/assets/*",
    "#Config": "./src/config.js",
    "#Lib": "./src/lib/index.js",
    "#Lib/*": "./src/lib/*",
    "#Models": "./src/models/index.js",
    "#Models/*": "./src/models/*",
    "#Styles/*": "./src/styles/*"
  }

Translating my imports map into tsconfig.json paths works as expected.

More information: https://nodejs.org/api/packages.html#subpath-imports

Current project - it works well with dependency for a file defined.
Proposal - how to define code level dependencies? for example, consider below code

var a = Object.keys(b)

Here a is dependent on Object.keys(b), hence a.dependency becomes Object.keys(b)

This will help the project to scale across and within a code as well.

With that intention, how can I define individual dependency pattern?

Hi, your library looks stunning, and especially the "check" dependency linting makes me want to try it out.
Unfortunately I'm having problems with installing it.

Trying to install it with npm (or pnpm) does not work, and produces the following error:

C:\Users\mkok>npm install --global @dep-tree/cli
npm ERR! code 1
npm ERR! path C:\Users\mkok\AppData\Roaming\nvm\v20.10.0\node_modules\@dep-tree\cli
npm ERR! command failed
npm ERR! command C:\Windows\system32\cmd.exe /d /s /c node install.js
npm ERR! Downloading dep-tree release from https://github.com/gabotechs/dep-tree/releases/download/v0.17.2/dep-tree_0.17.2_windows_amd64.tar.gz
npm ERR! Error: Could not find "dep-tree" in archive
npm ERR!     at extractFileFromTarGzip (C:\Users\mkok\AppData\Roaming\nvm\v20.10.0\node_modules\@dep-tree\cli\install.js:77:11)
npm ERR!     at install (C:\Users\mkok\AppData\Roaming\nvm\v20.10.0\node_modules\@dep-tree\cli\install.js:90:17)
npm ERR!     at process.processTicksAndRejections (node:internal/process/task_queues:95:5)

npm ERR! A complete log of this run can be found in: C:\Users\mkok\AppData\Local\npm-cache\_logs\2023-12-30T21_47_57_395Z-debug-0.log

The debug log can be found here
2023-12-30T21_47_57_395Z-debug-0.log

I have tried multiple older versions of dep-tree, they all produce the same error.

Here are some specs that might be relevant:

OS Platform: Windows 11 Enterprise
OS Version: 10.0.22631 Build 22631
node version: v20.10.0
npm version: 10.2.3

Please let me know if you need any more information, or if I can assist with further debugging.

Maybe the JSON output? If dep-tree could render that json, it could be a useful interchange format to build support in other languages.

For me, I was thinking about poking around and exploring this in a few Ruby codebases.