acrazing / dpdm Goto Github PK

I cannot make sense of the warnings. E.g. I got this:
1) skip "node_modules/class-transformer/esm5/index.js", issuers: "src/Graphviz.ts", "tests/json.test.ts"
both issuers need a part of class-transformer.
Graphviz.ts for example has a needed import:
import { Type } from 'class-transformer'
So, what is the problem I am warned about here?

Maybe you want to give a short comment for this in your README.md.
Great software, btw!

Is your feature request related to a problem? Please describe.

To analyze the application architecture, I need to know which modules are used by which other modules.

Describe the solution you'd like

Add option to output the reverted import tree. Ideally, I'd like to specify the files I like to see the output dependencies on the command line and additionally pass the application root file where to start analysis.

Describe alternatives you've considered

Do this manually somehow 😬

Hey there :) I just updated the dpdm to the latest version and always got this error Unknown argument: ENTRY_FILE_PATH when I ran something like "dpdm ENTRY_FILE_PATH".

Looks like it's related to the yargs upgrade(yargs/yargs#1977) that the strict() will throw error if there is any unknown argument. maybe the strictOptions() become a better choice now?

To reproduce in a TypeScript project, create a src folder, inside of that folder create a file called index.ts, then run:

npm i -g dpdm
dpdm src/index.ts

With version 3.6.0 or earlier, the output is correct and as expected (shows no circular dependencies found).

However with version 3.6.1 and 3.7.0 the output shows:

Unknown argument: src/index.ts

If I first run cd src and then run dpdm index.ts it's the same result.

Can reproduce on both macOS and Ubuntu.

can you change the package.json from UNLICENSE to MIT?

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

Describe the solution you'd like

I'd like to be able to efficiently run dpdm on multiple entrypoints concurrently.

Describe alternatives you've considered

I can provide a very large array of entrypoints, but analyzing things afterwards will be complicated.

Additional context

If dpdm would have cached parts of the dependency graph, it wouldn't have needed to re-construct parts of it in case of concurrent runs.

For example:

const [circulars1, circulars2] = await Promise.all([
  dpdm.parseCircular(await dpdm.parseDependencyTree(ep1, {
    context: cwd,
  })),
  dpdm.parseCircular(await dpdm.parseDependencyTree(ep2, {
    context: cwd,
  })),
])

If there's some overlap between ep1 and ep2's dependencies, we're doing unnecessary work, because we could have cached the first time.

Hi,
First of all thank you for this great tool.

However i found that using "import type" reported as circular dependency which in real it is not.

Can you fix it please.

Thanks

Hi. Thank you for this great tool. It helps us so much.
dpdm ignores node_modules by default. however in monorepo project it does not ignore root node_modules

$ dpdm src/** -T --exit-code circular:1 --tree false --warning false

✔ [11/11] Analyze done!
• Circular Dependencies
  ✅ Congratulations, no circular dependency were found in your project.

• Warnings
  1) skip "../../node_modules/@nestjs/common/index.js", issuers: "src/storage-core.module.ts", "src/storage.decorators.ts" (1 more...)
  2) skip "../../node_modules/minio/dist/main/minio.js", issuers: "src/providers/s3-storage-connection.ts"

Typescript allows "import type" for just a type require, and it will be ignored in complied .js file. My codes is here:

// file /contexts/task-request-context.ts:
import type Task from '../models/task.model';

// file /models/task.model.ts
import TaskRequestContext from '../contexts/task-request-context';

And I think they won't be Circular Dependencies.

Paths:

...
11) skip "dist/apps/project/node_modules/jwt-decode/build/jwt-decode.esm.js"
...

I've tried --exclude ".*node_modules.*", but it doesn't change anything.

I suppose 'dp' in 'dpdm' stands for dependency. What about the 'dm'?

Does it stand for dependency detective manager?
Or dependency data model?

Hello and thank you for your work. It's impressive how fast and straightforward dpdm is compared to other tools that aim to solve the same problem.

So far, I've used tslint-no-circular-imports and eslint-plugin-import with the no-cycle option enabled. They are way slower (especially the ESLint one), but one thing can be said about them: they integrate nicely with the ecosystem in which they are used. Using a lint rule is easy when you already have a linter in place, and can be extra powerful if the rule provides useful feedback right in your IDE of choice.

My question is: what are your recommendations for using dpdm?

• In your opinion, what is the best way for teams to integrate it into their workflow?
• Do you have any plans to turn it into an ESLint plugin, or is it a bad idea?
• Would it be possible to create a Visual Studio Code extension that utilizes dpdm and warns about circular dependencies during development?

Thank you again, and keep up the good work 🙇

Describe the solution you'd like

It would also be nice to be able to specify a directory and search for circular dependencies in it.

Perhaps it would look something like this

dpdm --no-warning \
     --no-tree \
     --directory ./src

The root file index.ts is not always available

Maybe we can implement the functionality using node-glob or something like that.

I'm using this package to require the whole directory. Do you think dpdm can detects in this case?
https://www.npmjs.com/package/require-directory

Because dpdm currently depends on typescript@^4.9.4, using the latest version of typescript and dpdm together will result in two different typescript versions being installed. This is quite an overhead in terms of the installation size, and it would be nice if dpdm would support typescript v5.

Describe the bug
Invoking dpdm on the command line with a file that doesn't exist produces the following very strange, but nonetheless misleadingly-positive output:

√ [0/0] Analyze done!
• Dependencies Tree


• Circular Dependencies
  ✅ Congratulations, no circular dependency was found in your project.

• Warnings

Importantly, you are not informed that the file was not found (or that there is even a problem at all).

To Reproduce

1. Enter dpdm ./this_file_does_not_exist_well_probably_I_mean_it_would_be_an_amazing_and_bizarre_coincidence.js on the command line
2. Press Enter

Expected behavior
The command line process aborts with an informative message when it does not find any file(s) to process.

Additional context
Windows 11

Trying to run dpdm on a TypeScript project, I get the following error:

TypeError: entriesDeep.flat is not a function
at Object. (C:\Tools\nvm\v10.16.3\node_modules\dpdm\lib\bin\dpdm.js:81:26)
at step (C:\Tools\nvm\v10.16.3\node_modules\dpdm\node_modules\tslib\tslib.js:139:27)
at Object.next (C:\Tools\nvm\v10.16.3\node_modules\dpdm\node_modules\tslib\tslib.js:120:57)
at fulfilled (C:\Tools\nvm\v10.16.3\node_modules\dpdm\node_modules\tslib\tslib.js:110:62)

@types/fs-extra and @types/yargs are currently listed as dependencies even though they are not relevant once dpdm is compiled/shipped.

This creates conflicts for downstream projects that use a different version of @types/fs-extra or @types/yargs

I've been looking for a tool that would be able to recursively extract all the dependencies given a single typescript file as an entry point. After looking around, I came back to dpdm, since I remembered that it must be able to generate a dependency tree in order to determine circular dependencies. I wasn't disappointed - parseDependencyTree does a really good job!

However, I would like to apply tree shaking after getting the tree and currently the tree doesn't contain any information about what each file imports/exports.

Would it make sense to record list of imports and exports in Dependency type as the tree is generated, and then use these in a subsequent step to shake the tree? By shaking the tree I mean, removing dependencies that are not directly imported (like unused modules that are re-exported in barrel files).

current:

 export interface Dependency { 
   issuer: string; 
   request: string; 
   kind: DependencyKind;
   id: string | null; // filename or shorten filename, cannot resolve will be null 
   imports: string[];
   exports: string[];
 } 

Maybe there is already some other tool out there that does this, but so far parseDependencyTree is the closest I've found.

Regarding the following code, which always appears when checking circular dependencies:

chalk.bold.red('• Circular Dependencies')

When scanning the output of DPDM, which I often run as part of a bigger collection of scripts/checks, seeing red text immediately makes me think there's a problem. This red text appears whether there are or are not circular dependencies.

I'd personally prefer no red text to be displayed (perhaps don't display this text at all) when there are no circular dependencies.

Happy to submit a PR if this is something you'd consider (but would need to know what your preferred option would be if so).

Thanks.

Hello and thank you for your work.

As recommended in #11, I decided to use dpdm in my CI pipeline. The remote build agent is using Windows, and that's where the issue manifests.

It seems like on Windows, the default value for the --exclude parameter ("\/node_modules\/") is not respected, and the tool finds circular dependencies in third-party code. That very same command works just fine when executed on macOS, skipping node_modules as expected.

Please let me know if any extra information is required to resolve this.

Is your feature request related to a problem? Please describe.
It's annoying that circular dependencies are shown when only a import type { ... } is involved

Describe the solution you'd like
having an option to ignore type imports

Describe alternatives you've considered
none

I'm getting a lot of warnings and one of them is:
lose "client/components/admin/configurations/columns" from "src/client/store/reducers/page-grid.ts"

I'm not really sure what to do in that case. Can you please give me a few details?

Thanks.

Use as a npm package should not import cli dependencies.

It always import cli packages like yargs, ora when I use it as a npm package, it is useless.

Describe the solution you'd like

Split to two package dpdm and dpdm-core, the first one should keep works with current version by importing dpdm-core, and the second one should not import cli related packages.

Describe alternatives you've considered

NO

Additional context

NO

I forked this repository and cloned it to my local, but after I installed the dependencies (by running yarn) I couldn't run the tests. I got this error:

Error [ERR_REQUIRE_ESM]: require() of ES Module /Users/USER/Desktop/dpdm/node_modules/string-width/index.js from /Users/USER/Desktop/dpdm/node_modules/cliui/build/index.cjs not supported.
Instead change the require of index.js in /Users/USER/Desktop/dpdm/node_modules/cliui/build/index.cjs to a dynamic import() which is available in all CommonJS modules.
    at Object.<anonymous> (/Users/USER/Desktop/dpdm/node_modules/cliui/build/index.cjs:291:21)
    at Object.<anonymous> (/Users/USER/Desktop/dpdm/node_modules/yargs/build/index.cjs:1:60678)
    at Object.<anonymous> (/Users/USER/Desktop/dpdm/node_modules/yargs/index.cjs:5:30)
    at _yargs (/Users/USER/Desktop/dpdm/node_modules/jest-cli/build/run.js:30:39)
    at buildArgv (/Users/USER/Desktop/dpdm/node_modules/jest-cli/build/run.js:149:26)
    at Object.run (/Users/USER/Desktop/dpdm/node_modules/jest-cli/build/run.js:124:24)
    at Object.<anonymous> (/Users/USER/Desktop/dpdm/node_modules/jest-cli/bin/jest.js:16:17)
    at Object.<anonymous> (/Users/USER/Desktop/dpdm/node_modules/jest/bin/jest.js:12:3)

Therefore I think the dependencies as declared in yarn.lock are broken.

My local dev env:

• Node v16.20.2 (node -v)
• Yarn 1.22.15 (yarn -v)
• MacOS Sonoma 14.1 (OS)
• Apple M1 Pro (chip)

I was able to work around this and run the tests by:

• deleting node_modules
• deleting yarn.lock
• running yarn (which installs the dependencies as declared in package.json, so unpinned versions)

Describe the bug

Vite supports aliases for imports. (Webpack has a very similar feature too).

When an import path contains such alias a warning is printed: miss "@/bar" in "src/foo.js".
Warning without a valid reason is not great by itself (in a real project I'm getting 78 of those), but I suspect it also means @/bar is considered missing and isn't checked for circular dependencies.

To Reproduce

1. Add following code to the vite.config.js:

export default defineConfig({
  [...]
  resolve: {
    alias: {
      '@': path.resolve(__dirname, './src/'),
    },
  },
  [...]
}

2. Create two files:

% cat src/bar.js
export function bar() {
  return 42
}

% cat src/foo.js
import { bar } from '@/bar'

console.log(bar())

3. Run dpdm:

yarn dpdm ./src/foo.js
/usr/local/Cellar/node/21.6.1/bin/node [
  '/Users/paul/mytrickyproject/node_modules/dpdm/lib/bin/dpdm.js',
  './src/foo.js'
]
✔ [1/1] Analyze done!
• Dependencies Tree
  - 0) src/foo.js
      - 1) @/bar

• Circular Dependencies
  ✅ Congratulations, no circular dependency was found in your project.

• Warnings
  1) miss "@/bar" in "src/foo.js"

Expected behavior

Warning about missing @/bar should not be printed, because it is, in fact, not missing.

Describe the bug

parseCircular incorrectly misses some of the circular dependencies in the tree given it.

To Reproduce

Run the tests introduced by:

• #42

Specifically:

const tree = {
  start: [dependencyFactory('left1'), dependencyFactory('right1')],
  left1: [dependencyFactory('left2')],
  left2: [dependencyFactory('intersection')],
  right1: [dependencyFactory('intersection')],
  intersection: [dependencyFactory('start')],
};

let actual: Array<string[]>;
beforeAll(() => {
  actual = parseCircular(tree);
});

it('Should count two cycles', () => {
  expect(actual.length).toBe(2);
});

it('Should include the ids involved in the cycle', () => {
  expect(actual[0]).toMatchObject([
    'start',
    'left1',
    'left2',
    'intersection',
  ]);
  expect(actual[1]).toMatchObject(['start', 'right1', 'intersection']);
});

function dependencyFactory(id: string): Dependency {
  return {
    issuer: '',
    request: '',
    kind: DependencyKind.StaticImport,
    id,
  };
}

Expected behavior

All tests should pass.

If we look at the dependency graph in the screenshots section, we expect to see 2 cycles:

[['start', 'left1', 'left2', 'intersection'], ['start', 'right1', 'intersection']]

Actual behavior

Some of the tests fail.

It correctly includes ['start', 'left1', 'left2', 'intersection'], but it incorrectly doesn't include ['start', 'right1', 'intersection'].

Screenshots

Additional context

Looks like it's related to

Hello,

Very nice package, I use it daily.
Is there a way I can hide the skip warnings?
Mainly because all of them comes from node_modules, where is not possible to get a circular dependency.

They appear at the end of the logs and hide up the Circular Dependencies result.

• Circular Dependencies
  ✅ Congratulations, no circular dependency were found in your project.

• Warnings
  01) skip "node_modules\\@babylonjs\\core\\Engines\\engine.js", issuers: "src\\modules\\engine\\engine.ts", "src\\modules\\scene\\scene.ts"
  02) skip "node_modules\\@babylonjs\\core\\Loading\\Plugins\\babylonFileLoader.js", issuers: "src\\core.ts"
  03) skip "node_modules\\@babylonjs\\core\\Loading\\loadingScreen.js", issuers: "src\\core.ts"
  04) skip "node_modules\\@babylonjs\\core\\Loading\\sceneLoader.js", issuers: "src\\modules\\assets-manager\\assets-manager.ts"
  05) skip "node_modules\\@babylonjs\\core\\Materials\\PBR\\pbrMaterial.js", issuers: "src\\core.ts"
  06) skip "node_modules\\@babylonjs\\core\\Materials\\Textures\\dynamicTexture.js", issuers: "src\\misc\\dynamic-texture-helper.ts"
  07) skip "node_modules\\@babylonjs\\core\\Maths\\math.color.js", issuers: "src\\modules\\scene\\scene.ts"
  08) skip "node_modules\\@babylonjs\\core\\Maths\\math.vector.js", issuers: "src\\misc\\vectors.ts", "src\\models\\display-object.ts" (5 more...)
  09) skip "node_modules\\@babylonjs\\core\\Meshes\\mesh.js", issuers: "src\\models\\display-object.ts", "src\\modules\\mesh\\mesh.ts"
  10) skip "node_modules\\@babylonjs\\core\\Sprites\\sprite.js", issuers: "src\\models\\display-object.ts", "src\\modules\\sprite\\sprite.ts"
  11) skip "node_modules\\@babylonjs\\core\\Sprites\\spriteManager.js", issuers: "src\\modules\\sprite\\sprite-texture.ts"
  12) skip "node_modules\\@babylonjs\\core\\index.js", issuers: "src\\modules\\sprite\\sprite-texture.ts"
  13) skip "node_modules\\@babylonjs\\core\\scene.js", issuers: "src\\misc\\dynamic-texture-helper.ts", "src\\misc\\sprite-texture-helper.ts" (9 more...)
  14) skip "node_modules\\@babylonjs\\gui\\2D\\advancedDynamicTexture.js", issuers: "src\\modules\\gui\\gui.ts"
  15) skip "node_modules\\@babylonjs\\gui\\2D\\controls\\control.js", issuers: "src\\modules\\gui\\gui.ts"
  16) skip "node_modules\\@babylonjs\\gui\\2D\\controls\\textBlock.js", issuers: "src\\modules\\gui\\gui.ts"
  17) skip "node_modules\\rxjs\\dist\\esm5\\fetch\\index.js", issuers: "src\\modules\\assets-manager\\assets-manager.ts"
  18) skip "node_modules\\rxjs\\dist\\esm5\\index.js", issuers: "src\\models\\animation-keyframe.ts", "src\\models\\core-globals.ts" (7 more...)
  19) skip "node_modules\\rxjs\\dist\\esm5\\operators\\index.js", issuers: "src\\modules\\assets-manager\\assets-manager.ts"

I have an index.ts that is the main entry point from which I export all Firebase cloud functions.

However, files still appear as "unused" even though I'm directly exporting them from this file.

Anything I can do here?

We have some ES6 modules which import eachother by package name. In other words package Foo has a.js and b.js, and b.js imports from "Foo/a". It seems dpdm doesn't understand this. It'd be good to have some way to say "Foo points at the current directory" or similar, maybe something like https://developer.mozilla.org/en-US/docs/Web/HTML/Element/script/type/importmap

Describe the bug

When running with a glob such as 'src/**/*.js', it will not run for files directly under js (I suspect it has something to do with greediness in one of the glob packages, since running glob from npm and ls src/**/*.js return the right amount of files).

To Reproduce

Create a project with the following structure:
src/
index.js
folder1/
temp1.js
folder2/
temp2.js

Run dmdm src/**/*.js

Expected behavior

dmdm should run on 3 files - temp1.js, temp2.js, index.js

Screenshots

Additional context

Describe the bug
I get different output from dpdm depending on the folder where it was run. For example, if I have a structure like web/apps/<app_name>/src/index.ts then if I run the command from /web it says "0 circular dependencies". However, if I run it one level deeper (still targeting the same index.ts) it says "68 circular dependencies"

To Reproduce

1. Try dpdm ./a/b/c/index.ts > output1.txt
2. cd ./a
3. dpdm ./b/c/index.ts > output2.txt
4. Compare output1 and output2, they are different

Expected behavior
Should produce the same result no mater cwd I guess.

Additional context
I found the issue when I fixed huge amount of circular deps, then merged and then decided to try once again after the merge. I noticed the circular depts weren't fixed, but after a while I understood that I execute the command from different folders.

Describe the bug

I have a large TypeScript project and have set up DPDM in my test process to detect circular dependencies imported by index.ts. The project has several circular type dependencies so I'd like to use dpdm -T src/modules/index.ts. However, this fails to detect several actual cycles: the one that prompted this test throws a ReferenceError: can't access lexical declaration before initialization when run.

In addition the tree for index.ts doesn't show 97% of its direct dependencies (none of which are types) and 40% of them are missing from the tree entirely! Most of them are referenced after being imported (being Object.assigned to window)

For the moment I'm using dpdm --no-tree -T src/modules/**/*.ts instead as this does seem to detect all the actual cycles, but resolving them is much harder without reliable trees. This approach also scans a handful of files that aren't accessible from index.ts, though that's not a big deal.

To Reproduce

I can reproduce it with this simplification of the circular dependency I first noticed the issue with.

index.ts:

import A from './A';
import B from './B';
import C from './C';

A.ts:

import C from './C';

export default class A {
    static list = [{ text: 'Example A', class: new C(0) }];
}

B.ts:

import A from './A';

export default class B {
    static list = [{ text: 'Example B' }];

    static getText(i) {
        return `${B.list[i]} ${A.list[i]}`;
    }
}

C.ts:

import B from './B';

export default class C {
    constructor(public i: number) { };

    public getText() {
        return B.list[this.i].text;
    }
}

dpdm index.ts correctly detects the cycle. dpdm -T index.ts does not detect the cycle and shows no dependencies for index.ts in its tree. dpdm -T A.ts detects the cycle and shows the correct tree, as does dpdm -T B.ts and dpdm -T C.ts.

Referencing any of the imports in index.ts causes it to detect the cycle again, but it isn't consistent in ways I don't understand. Adding Object.assign(<any>window, { A, B }); works in this example but doesn't in my project, and even with that line C is still missing from index.ts's direct dependencies.

Expected behavior

Using the transform flag should ignore type dependencies without other changes to the dependency tree.

Additional context

Thanks for making DPDM! Even with the current weirdness, it's been extremely helpful for tracking down a couple evasive bugs.

Describe the bug

• On every commit we run yarn dpdm --no-warning --no-tree ./src/**/* > circularDependencies.txt
• For some of the developers working on the project this is producing an inconsistent output, toggling the circularDependencies.txt file between two states, one being the correct output and the other is incorrect containing about 1/3rd of the content that it should.
• We've been able to identify one difference when running the command between developers who have the issue and those who do not
  • Those who don't have the issue will get this message after running the command ✔ [997/997] Analyze done!
  • Those who do have the issue will have a value of 1 lower for in the message ✔ [996/996] Analyze done!.

To Reproduce
Steps to reproduce the behavior:

1. Run yarn dpdm --no-warning --no-tree ./src/**/* > circularDependencies.txt
2. This will occasionally result in the circularDependencies.txt changing even if there have been 0 changes since the last time the command was run
3. Run yarn dpdm --no-warning --no-tree ./src/**/* > circularDependencies.txt again and it will changing back to it's previous state
4. Note: Sometimes this happens every time the command is run and sometimes it only happens every ~5 or so times

Expected behaviour

• We expect a consistent output in the circularDependencies.txt file that is accurate

Screenshots
Here is an example of the file being toggled on back to back empty commits.

Is your feature request related to a problem? Please describe.

It would be nice if we were able to run this tool together with lint-staged to report dependency cycles for staged/modified files, without having to manually skip through cycles in the rest of the project.

Describe the solution you'd like

A new CLI flag (--only maybe?) that tells dpdm to only return cycles that directly reference the file paths passed as arguments.

Describe alternatives you've considered

Running dpdm and then grepping kinda works when only passing a single file, but doesn't work as well for multiple files.

npx dpdm -T --skip-dynamic-imports circular --no-tree --no-warning $files | grep $files

Additional context

None

currently dpdm is detecting dynamic imports as an issue but that's not always the case.
can we set it so dynamic imports & require are ignored?

Is your feature request related to a problem? Please describe.
instead of file basead I'd like to see dependency and circular dependency in a package based view

Describe the solution you'd like

a package based view flag

Describe alternatives you've considered

trying to customize the cli

Additional context

we have a monorepo with many packages, we want to ensure and avoid circular dependencies

Describe the bug

Exclude doesn't seem to work.

To Reproduce

Create a folder with this structure

src 
    - index.ts
    - index.test.ts
    - package.json

It should not matter for this issue but the files look like this

index.ts

export const test = () => console.log('hi');

test()

index.test.ts

import { test } from "node:test"
import assert from "node:assert"

test("some test", (t) => {
    assert.strictEqual(1, 1)
  })
  
  test("second basic test", () => {
    assert.equal(2, 3)
  })

package.json

{
  "name": "dpdm-example",
  "version": "1.0.0",
  "author": "Foo Bar <[email protected]>",
  "scripts": {
    "test": "node --loader tsx --test *test.ts"
  },
  "devDependencies": {
    "tsx": "^4.7.0"
  }
}

Run
From within the src directory, run
$ npx dpdm --no-tree --detect-unused-files-from '**/*.*' index.ts --exclude node_modules --include *.ts

And note that you still see the node_modules and test files returned as unused

00) index.test.ts
01) node_modules/@esbuild/darwin-arm64/README.md
02) node_modules/@esbuild/darwin-arm64/package.json
03) node_modules/esbuild/LICENSE.md
04) node_modules/esbuild/README.md
05) node_modules/esbuild/install.js
06) node_modules/esbuild/lib/main.d.ts
07) node_modules/esbuild/lib/main.js
08) node_modules/esbuild/package.json
09) node_modules/fsevents/README.md
10) node_modules/fsevents/fsevents.d.ts
11) node_modules/fsevents/fsevents.js
12) node_modules/fsevents/fsevents.node
13) node_modules/fsevents/package.json
14) node_modules/get-tsconfig/README.md
15) node_modules/get-tsconfig/dist/index.cjs
16) node_modules/get-tsconfig/dist/index.d.cts
17) node_modules/get-tsconfig/dist/index.d.mts
18) node_modules/get-tsconfig/dist/index.mjs
19) node_modules/get-tsconfig/package.json
20) node_modules/resolve-pkg-maps/README.md
21) node_modules/resolve-pkg-maps/dist/index.cjs
22) node_modules/resolve-pkg-maps/dist/index.d.cts
23) node_modules/resolve-pkg-maps/dist/index.d.mts
24) node_modules/resolve-pkg-maps/dist/index.mjs
25) node_modules/resolve-pkg-maps/package.json
26) node_modules/tsx/README.md
27) node_modules/tsx/dist/cjs/index.cjs
28) node_modules/tsx/dist/cjs/index.mjs
29) node_modules/tsx/dist/cli.cjs
30) node_modules/tsx/dist/cli.mjs
31) node_modules/tsx/dist/client-2f0df4a6.cjs
32) node_modules/tsx/dist/client-e665d820.mjs
33) node_modules/tsx/dist/esm/index.cjs
34) node_modules/tsx/dist/esm/index.mjs
35) node_modules/tsx/dist/get-pipe-path-86e97fc9.cjs
36) node_modules/tsx/dist/get-pipe-path-b74d9893.mjs
37) node_modules/tsx/dist/index-5d1f01e6.cjs
38) node_modules/tsx/dist/index-bd1ceb03.mjs
39) node_modules/tsx/dist/loader.cjs
40) node_modules/tsx/dist/loader.mjs
41) node_modules/tsx/dist/node-features-c450ed54.cjs
42) node_modules/tsx/dist/node-features-fb266590.mjs
43) node_modules/tsx/dist/package-22dbf202.cjs
44) node_modules/tsx/dist/package-a2d7442c.mjs
45) node_modules/tsx/dist/pkgroll_create-require-b92e8e0d.mjs
46) node_modules/tsx/dist/pkgroll_create-require-c530e400.cjs
47) node_modules/tsx/dist/preflight.cjs
48) node_modules/tsx/dist/preflight.mjs
49) node_modules/tsx/dist/repl.cjs
50) node_modules/tsx/dist/repl.mjs
51) node_modules/tsx/dist/resolve-ts-path-3fca13b7.cjs
52) node_modules/tsx/dist/resolve-ts-path-eb3847f5.mjs
53) node_modules/tsx/dist/source-map.cjs
54) node_modules/tsx/dist/source-map.mjs
55) node_modules/tsx/dist/suppress-warnings.cjs
56) node_modules/tsx/dist/suppress-warnings.mjs
57) node_modules/tsx/dist/temporary-directory-04b36185.mjs
58) node_modules/tsx/dist/temporary-directory-2a027842.cjs
59) node_modules/tsx/package.json
60) package-lock.json
61) package.json

Expected behavior

node_modules and paths with test in the name are excluded from the output

Wondering if the following is currently supported, and if not then perhaps you could treat it as a feature request.

Currently, parsing the dependency tree stops when it reaches the shortest path export. Is there a way to configure dpdm to continue down the import chain in the case that that path is just a re-export of an import?

For example,

c.ts

export const foo = {};

b.ts

export * from './c'

a.ts

import { foo } from './b`

in this case the dependency graph would resolve to ./c.ts instead of ./b.ts

First of all, thank you for this amazing project!

Sadly, I find it useless for me, because it handles type-only dependencies as a regular ones. As far as I know, they are ignored in runtime, so there is no reason to count them. Last version of TS also use import type syntax to state it explicitly, it would be nice to ignore at least this kind of imports.

Also, I think node_modules should be ignored by default.

When integrating dpdm with CI, it would be nice if the cli tool would terminate with exit code 1 if any circular dependencies are found. Or, if it at least provided a flag to enable this behaviour.

What are your thoughts on this? Would gladly submit a PR if you are accepting contributions.

Is your feature request related to a problem? Please describe.
On larger projects, I find path aliasing to be indispensable. Unfortunately, DPDM doesn't appear to support resolving paths from tsconfig, hiding a significant number of potential circular dependencies.

Describe the solution you'd like
I would like DPDM to be able to resolve path aliases, and highlight circular dependencies caused by aliased imports.

Describe alternatives you've considered
I am currently doing a large find-and-replace on aliases across my code-base so I can use DPDM (it's really a great tool and worth the effort!). Once I find the dependency I'll revert the changes. It's a bit intensive, but it'll get the job done.

Additional context
Cli comes back with a message something like this:

• Circular Dependencies
  ✅ Congratulations, no circular dependency was found in your project.

• Warnings
  1) miss "@api/H***.utils" in "r***.consts.ts"
  2) miss "@api/O***.utils" in "r***.consts.ts"
  3) miss "@api/T***" in "r***.consts.ts"
  4) miss "@api/T***.utils" in "r***.consts.ts"
  5) miss "@api/i***" in "r***.consts.ts"
  6) miss "@api/s***.utils" in "r***.consts.ts"
  7) miss "@utils/a***" in "r***.consts.ts"
  8) miss "@utils/t***" in "r***.consts.ts"

Is your feature request related to a problem? Please describe.
To analyze the application architecture, I need to know which modules import files from which other modules.

Describe the solution you'd like

I would like to have an option like --max-depth=1 to limit the depth of the output to show just direct dependencies.

Describe alternatives you've considered

For now, I use grep -v to remove unwanted output.

Additional context

Thank you for this lib!

I've noticed a bug around context option. Searching for dependencies using custom context does not work as expected.

Perhaps it's because you use const currentDirectory = process.cwd(); instead of const currentDirectory = options.context in

To workaround this I had to do the following, but I would rather not :D

// dpdm does not support custom search directory :/
const oldProcessCwd = process.cwd
process.cwd = () => cwd

deps = cleanupDpdmDeps(
  await parseDependencyTree(entryPoints, {
    context: cwd // does not work as expected
  })
)

process.cwd = oldProcessCwd

https://github.com/jayu/rev-dep/blob/master/src/lib/getDepsTree.ts#L15-L25