acrazing / dpdm Goto Github PK
View Code? Open in Web Editor NEWDetect circular dependencies in your TypeScript projects.
License: MIT License
Detect circular dependencies in your TypeScript projects.
License: MIT License
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
?
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
dpdm ./this_file_does_not_exist_well_probably_I_mean_it_would_be_an_amazing_and_bizarre_coincidence.js
on the command lineExpected 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)
Lines 63 to 65 in 5dd1d67
@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:
Lines 20 to 25 in 5dd1d67
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 -v
)yarn -v
)I was able to work around this and run the tests by:
node_modules
yarn.lock
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
vite.config.js
:export default defineConfig({
[...]
resolve: {
alias: {
'@': path.resolve(__dirname, './src/'),
},
},
[...]
}
% cat src/bar.js
export function bar() {
return 42
}
% cat src/foo.js
import { bar } from '@/bar'
console.log(bar())
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:
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
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
dpdm ./a/b/c/index.ts > output1.txt
cd ./a
dpdm ./b/c/index.ts > output2.txt
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.assign
ed 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
yarn dpdm --no-warning --no-tree ./src/**/* > circularDependencies.txt
β [997/997] Analyze done!
β [996/996] Analyze done!
.To Reproduce
Steps to reproduce the behavior:
yarn dpdm --no-warning --no-tree ./src/**/* > circularDependencies.txt
yarn dpdm --no-warning --no-tree ./src/**/* > circularDependencies.txt
again and it will changing back to it's previous stateExpected behaviour
circularDependencies.txt
file that is accurateScreenshots
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
Line 136 in c389480
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
A declarative, efficient, and flexible JavaScript library for building user interfaces.
π Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. πππ
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google β€οΈ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.