dependents / node-dependency-tree Goto Github PK

import 'assets/styles/default.scss'; working in macOS, but not working in Windows. Path doesn't resolve and dependencies not found.

After #25 lands, we need tests for config support.

Hi,

Is there a way to return the line (where the dependency was found) in addition to the filepath?

Thank you

Filter is a function that accepts an object containing a few properties of the given file and returns a boolean indicating whether or not to include the file in the tree generation.

• filepath (all for now but prevents a breaking change in the future)

• Allows us to solve #37 by omitting files that contain node_modules in their path
• Allows us to implement dependents/Dependents#224 by parsing the file, sniffing if it's a React component, then returning true/false.

If you change the following code in the traverse function:

var tree = [filename];
...
// Prevents redundancy about each memoized step
tree = removeDups(tree);

...to the following:

var tree = []; // now empty
...
tree = tree.concat(filename); // added

// Prevents redundancy about each memoized step
tree = removeDups(tree);

...the resulting list should be the equivalent of a post-order traversal of the dependency tree, with the entry file as the last element in the list. The list would not only give you the set of files in the dependency tree, it would give you the proper concatenation order of the source files when bundling the files as part of a build.

• Use node-style callbacks
• Change root to directory in source
• Support an options object with the params instead of positional arguments
• This module should expose getTreeAsList as exports
• Change docs such that this is not a collection of 'utility' functions

I see y’all did a major version release—how do I find out what changed?

Refs #66

For example:

// mod-a.js
export const a = (x) => x + 1
export const b = (x) => x - 1
export const c = (x) => x * 1

// mod-b.js
import {a, b} from "mod-a"
export const n = (x) => a(b(x))

// output
{
  file: 'mod-b.js',
  exports: ['n'],
  depends: [{
    file: 'mod-a.js',
    exports: ['a', 'b', 'c'],
    used: ['a', 'b']
  }]
}

As request in #23, a new issue tracking support for webpack.

Use stats? Or just consume the config from webpack?

Hey all!

I saw that you bumped the version of node-filing-cabinet to 2.5.1 here in 31c0ce5 , with support for noTypeDefinitions.

There doesn't seem to be a way to pass this as a param.
I'd be happy to make PR for this.

Is there any support for precinct es6.mixedImports in dependency-tree cli?

Currently only uses the naive file resolution. Needs to use methods specific to filetypes.

Bad title, but I think that's the reason. 😆

Let's see if I can explain what (I think) is happening:
We have a dependency on yargs, which depends on yargs-parser, which uses lodash.assgin@4. We also use babel-eslint, which uses lodash.assign@3. lodash.assign@4 has dependencies on lodash.rest and lodash.keys, while lodash.assign@3 has dependencies on lodash._baseassign, lodash._createassigner and lodash.keys.

npm@3 puts lodash.assign@3 and lodash.rest in my projects node_modules, but keeps lodash.assign@4 in yargs-parser's node_modules.

Now, the problem:
dependency-tree references the lodash.assign@3 in my project's node_modules, instead of the right one for yargs-parser.

$ npm ls lodash.assign -p
/home/testyo/repos/frontend-repo/code/node_modules/lodash.assign
/home/testyo/repos/frontend-repo/code/node_modules/yargs-parser/node_modules/lodash.assign

I think you have an optimization which says "oh, lodash.assign is already added, moving on", instead of handling the fact that multiple versions are installed.

Do you understand the error, or should I try to create a reproducible sample?

This way, you don't try to dig all the way down into hell

Is there a way (or other tool/package) to see a reverse dependency tree, i.e. which files depend on a given file?

In Serverless Framework we started to use dependency-tree to resolve dependencies tree for Node.js AWS lambdas, still we found out that it increased size of a Framework installation by 70MB, and size of our standalone binary iby 30MB

As we investigated, reason is that typescript started to be included in a project, when it's not really needed by it.

I believe right approach would be to not list typescript as a dependency, but require TypeScript to be installed aside (which naturally is the case) if one uses dependency-tree in context of TypeScript project.

Related issue on our side: serverless/dashboard-plugin#423

Hello! I came from madge library source code attempting to find the answer "How to resolve typescript import path aliases" :)

Standard import produces correct graph, but imports like import { Omit } from '~/types/Omit'; are't tracked.

Thank you

Awesome tool, we'd like to visualise our LESS dependencies.

Unfortunately we use the ~ notation to use node style imports within less, which are supported thanks to less-loader:

@import '~antd/lib/style/color/colors';

This gets resolved to the closest node module with the name of antd.

It seems like node-dependency-tree is not able to resolve those imports.

I've been generating a lot of dependency graphs which upon closer inspection are missing some very important modules! After sleuthing through this library and the libraries that it uses, I discovered that the missing modules could not be resolved! This was kind of painful because the failures are silenced and there doesn't appear to be an option to make them not silent. I ended up using DEBUG=cabinet to get the stack traces, but that was a pretty hidden feature.

Either module resolution errors should not be silent (unless some explicit quiet flag is passed in) or there should be a big warning that your dependency graph might be incomplete of modules fail to resolve.

What do you think?

I don't see the point of the directory option. What does it even do? Can this be documented? I feel like the filename option is all the client needs to provide. For example, "give me the dependency tree starting at the given filename". Thanks.

Could avoid unnecessarily recomputing dependencies. This would be a massive time saving.

When running dependency-tree --directory test/files/amd/ok test/files/amd/ok/a.js on the file https://github.com/pahen/madge/blob/develop/test/files/amd/ok/a.js I get this:

{
  "/Users/patrik/Code/madge/test/files/amd/ok/a.js": {
    "/Users/patrik/Code/madge/test/files/amd/ok/sub/b.js": {}
  }
}

When I expected this:

{
  "/Users/patrik/Code/madge/test/files/amd/ok/a.js": {
    "/Users/patrik/Code/madge/test/files/amd/ok/sub/b.js": {
      "/Users/patrik/Code/madge/test/files/amd/ok/sub/c.js": {
        "/Users/patrik/Code/madge/test/files/amd/ok/d.js": {}
      }
    }
  }
}

If I create a RequireJS config with baseUrl: '.' and run dependency-tree --directory test/files/amd/ok --require-config test/files/amd/ok/config.js test/files/amd/ok/a.js I get this:

{
  "/Users/patrik/Code/madge/test/files/amd/ok/a.js": {
    "test/files/amd/ok/sub/b.js": {
      "test/files/amd/ok/sub/c.js": {
        "test/files/amd/ok/d.js": {}
      }
    }
  }
}

Which is almost what I expected except the wrong paths. Do you have any thoughts on this @mrjoelkemp?

First off, thank you so much for this library. I've tried a handful of dependency tree libraries that simply didn't work, or didn't do what I needed. This is the first one that's done almost everything I need, and is blazingly fast at it.

I was wondering if the library currently supports (didn't see anything in the source) the ability to define multiple lookup paths, besides the JS source root. For example, I include lodash functionality into my modules: https://github.com/titon/toolkit/blob/3.0/js-es6/Element.js#L9 Currently the library will skip over the lodash modules.

Perhaps something like a SystemJS style path map: https://github.com/titon/toolkit/blob/3.0/tests-es6/runner.js#L16

Create a function that returns the path to the given file. From the driver script(s) to the file.

I'm having trouble getting dependency-tree to follow ts imports from js files. For instance if I define:

// one.ts
import {two} from './two';

export function one() {
  console.log('one');
  two()
}

// two.js
import {three} from './three';

export function two() {
  console.log('two');
  three()
}

// three.ts
import {four} from './four';

export function three() {
  console.log('three');
  four()
}

// four.js
export function four() {
  console.log('four');
}

when I run dependency-tree on the source code:
dependency-tree --directory='.' one.ts

I get the following output:

{
  "one.ts": [
    "two.js"
  ],
  "two.js": []
}

But I'm expecting dependency-tree to be able to resolve the typescript import from a javascript file. Is there any documentation on how to do this? It seems like a common enough case.

Hello!

Maybe I'm creating an issue in the wrong repository and real problem hides somewhere in dependencies. But I use dependency-tree as an entry point, so ... it looks like a good start.

Let's imagine that we have the following directory layout:

<project>
  |
  - package.json
  - node_modules
  |    |
  |    - package1
  |         |
  |         - index.js
  |
  - dist <- dependency-tree `directory` argument
       |
       - package.json
       - src
            |
            - index.js  <- dependency-tree `filename` argument (path.join(..., 'dist', 'src', 'index.js'))
       - node_modules
            |
            - package2
                 |
                 - index.js
                 - node_modules
                      |
                      - package1
                           |
                           - index.js                      

I invoke dependency-tree with the following arguments:

{
  directory: path.join(<project>, 'dist'),
  filename: path.join(<project>, 'dist/src/index.js')
}

And index.js requires package2 module. Which, respectively, requires package1 module. The folder where package2 resides was initiated by the following command: npm i --global-style, i.e. dependencies of modules from package.json are put into local node_modules folders of each package. In other words - I want to maintain old-style node_modules directory layout (let's pretend that I like duplicates :) ), where each top-level module holds its modules with itself.

And here is the problem. Top level directory () also contains node_modules with package1. And when I receive output from dependency-tree I have something like this:

.../dist/src/index.js
.../dist/node_modules/package2/index.js
.../node_modules/package1/index.js

NOT:

.../dist/src/index.js
.../dist/node_modules/package2/index.js
.../dist/node_modules/package2/node_modules/package1/index.js

If I'm not mistaken this algorithm assumes the second variant (it starts to look at the nearest node_modules folder and traverses to the root of the file system).

Am I wrong or something works not as expected? I have some checks after receiving list from dependency-tree. One of them is confirmation that common directory for all imports is dist folder. And this check started to fall when I tried to use npm i command inside dist folder with --global-style argument. Without it (when package1 folder resides at the same level as package2) all works as expected.

Can you confirm that I'm wrong :) or help to resolve the issue?
Thanks in advance! CC: @mrjoelkemp

See: https://github.com/mrjoelkemp/node-filing-cabinet

Yields better partial resolution.

Could resolve #23.

@mrjoelkemp: Hi, I like your dependency-tree tool. But unfortunately it doesn't meet my requirements. I use SystemsJS that uses a system.config.js file to map the paths of modules to specific name. See below:

import * from 'angular'
import lodash from 'lodash'

with 'lodash' declared in the system.config.js like so:

'lodash' : 'node_modules/lodash/lodash.js'
'angular' : 'lib/angular/angular.js'

So essentially module path resolution should take place based on the keys in your system.config.js I've looked at the code and I would love to try my hand at adding support for SystemJS. I've already played with your code and I have the basics working.

Hello,

please consider to rename the cli executable name, since tree is a common utility in linux.

09:38 $  tree --version
tree v1.7.0 (c) 1996 - 2014 by Steve Baker, Thomas Moore, Francesc Rocher, Florian Sesser, Kyosuke Tokoro

Along the way to building the list, add things to a js object

This should not be a breaking change. root should be deprecated. This aligns dependency-tree with the other packages that are related to Dependents.

Useful for getting a more complete picture of dependents/Dependents#55

We should only put valid files in the tree.

I am trying to get a dynamic import tree with Typescript.
But I can't get this.

// directory
index.js
js-test.js
a.js
dynamic.js

js-test.js

import a from './a';
const dynamic = import('./dynamic');

index.js

const path = require('path')
var dependencyTree = require('dependency-tree');
main();
function main() {
  const jsPath = path.resolve(process.cwd(), '/js-test.js');

  const Tree = dependencyTree({
    filename: __dirname + jsPath,
    directory: __dirname,
  });
  console.log(Tree);
}

// Output
{
  '/Users/myUsername/workspace/js-test.js': {
    '/Users/myUsername/workspace/a.js': {},
    '/Users/myUsername/workspace/dynamic.js': {}
  }
}

I can get a tree with dynamic import in js.

but...

// directory
index.js
ts-test.ts
a.ts
dynamic.ts

ts-test.ts

import a from './a';
const dynamic = import('./dynamic');

index.js

const path = require('path')
var dependencyTree = require('dependency-tree');
main();
function main() {
  const jsPath = path.resolve(process.cwd(), '/ts-test.ts');

  const Tree = dependencyTree({
    filename: __dirname + jsPath,
    directory: __dirname,
  });
  console.log(Tree);
}

// Output
{
  '/Users/myUsername/workspace/ts-test.ts': {
    '/Users/myUsername/workspace/a.ts': {},
  }
}

Precss syntax for @import simmilar to sass

I get this after a fresh install:

$ dependency-tree
internal/modules/cjs/loader.js:605
    throw err;
    ^

Error: Cannot find module 'eslint/lib/util/traverser'
    at Function.Module._resolveFilename (internal/modules/cjs/loader.js:603:15)
    at Function.Module._load (internal/modules/cjs/loader.js:529:25)
    at Module.require (internal/modules/cjs/loader.js:657:17)

Would be nice if this was mentioned somewhere - just getting a call stack is not ideal.

Filing-cabinet dependency had a TS error when trying to reassign a const variable introduced on v1.14.4. This issue was fixed on filing-cabinet v2.0.1 but as the minimum required version on dependency-tree is v1.14.3, if you happened to download any version between v1.14.4 and 2.0.0 you would get an error.

Bumping filing-cabinet minimum version to 2.0.1 on the next dependency-tree upgrade would eliminate this issue.

Today the same file content is read in both precinct at https://github.com/mrjoelkemp/node-dependency-tree/blob/master/index.js#L104 and cabinet at https://github.com/mrjoelkemp/node-dependency-tree/blob/master/index.js#L134.

So one AST is create for getting the dependencies and one for getting the type when resolving the file.

If we could find a good way to only read file content and create the AST once per file we should probably see a huge performance boost.

Currently, if a file has been visited, it is not included in other trees that also have that file. We should still see that file and its resulting tree included, but we should not recompute its tree.

At each step, you need to remember the tree.

When you encounter a file that's already been visited, append its tree to yours (make sure its tree has the file itself).

At the end of the traversal, the tree for the initial file is the resulting tree.

I am unable to resolve the dependency if I'm importing a directory with an index.ts file.

For example . . .
src/index.ts

export default class Hello {}

tests/index.ts

import Hello from '../src'

Instead, what I have to do to make it work is explicitly import the index, which is less ideal.
src/index.ts

export default class Hello {}

tests/index.ts

import Hello from '../src/index'

Here is the debug log for running the following command.

DEBUG=* dependency-tree --directory="." --list-form tests/index.ts

  tree given filename: tests/index.ts +0ms
  tree resolved filename: /home/codejamninja/Projects/generator-node-module-typescript/demo/tests/index.ts +1ms
  tree visited:  {} +0ms
  tree traversing /home/codejamninja/Projects/generator-node-module-typescript/demo/tests/index.ts +0ms
  precinct paperwork: stripping the dot from the extension to serve as the type +0ms
  precinct paperwork: setting the module type +0ms
  precinct paperwork: invoking precinct +0ms
  precinct options given:  { includeCore: false, type: 'ts' } +0ms
  precinct module type:  ts +0ms
  typescript-eslint:typescript-estree:createSourceFile Getting AST without type information in TS mode for: /home/codejamninja/Projects/generator-node-module-typescript/demo/estree.ts +0ms
  tree extracted 1 dependencies:  [ '../src/index' ] +9ms
  cabinet Given filename: /home/codejamninja/Projects/generator-node-module-typescript/demo/tests/index.ts +0ms
  cabinet which has the extension: .ts +0ms
  cabinet found a resolver for .ts +0ms
  cabinet performing a typescript lookup +0ms
  cabinet given typescript config:  undefined +0ms
  cabinet no tsconfig given, defaulting +0ms
  cabinet processed typescript config:  undefined +0ms
  cabinet processed typescript config type:  undefined +0ms
  cabinet with options:  { module: 2 } +0ms
  cabinet result: /home/codejamninja/Projects/generator-node-module-typescript/demo/src/index.ts +1ms
  cabinet resolved path for ../src/index: /home/codejamninja/Projects/generator-node-module-typescript/demo/src/index.ts +0ms
  tree cabinet-resolved all dependencies:  [
  '/home/codejamninja/Projects/generator-node-module-typescript/demo/src/index.ts'
] +2ms
  tree given filename: /home/codejamninja/Projects/generator-node-module-typescript/demo/tests/index.ts +11ms
  tree resolved filename: /home/codejamninja/Projects/generator-node-module-typescript/demo/tests/index.ts +0ms
  tree visited:  {
  '/home/codejamninja/Projects/generator-node-module-typescript/demo/tests/index.ts': []
} +0ms
  tree traversing /home/codejamninja/Projects/generator-node-module-typescript/demo/src/index.ts +0ms
  precinct paperwork: stripping the dot from the extension to serve as the type +11ms
  precinct paperwork: setting the module type +0ms
  precinct paperwork: invoking precinct +0ms
  precinct options given:  { includeCore: false, type: 'ts' } +0ms
  precinct module type:  ts +0ms
  typescript-eslint:typescript-estree:createSourceFile Getting AST without type information in TS mode for: /home/codejamninja/Projects/generator-node-module-typescript/demo/estree.ts +10ms
  tree extracted 0 dependencies:  [] +1ms
  tree cabinet-resolved all dependencies:  [] +1ms
  tree traversal complete Set {
  '/home/codejamninja/Projects/generator-node-module-typescript/demo/src/index.ts',
  '/home/codejamninja/Projects/generator-node-module-typescript/demo/tests/index.ts'
} +0ms
  tree deduped list of nonExistent partials:  [] +0ms
  tree list form of results requested +0ms
  tree final tree [
  '/home/codejamninja/Projects/generator-node-module-typescript/demo/src/index.ts',
  '/home/codejamninja/Projects/generator-node-module-typescript/demo/tests/index.ts'
] +0ms
/home/codejamninja/Projects/generator-node-module-typescript/demo/src/index.ts
/home/codejamninja/Projects/generator-node-module-typescript/demo/tests/index.ts

Breaking change

In our source code, we have imports that do not have paths, and that are not node-modules. For example:

import 'special-library.lib.js'

Currently, when I try to get the dependency tree, this file shows up in the nonExistent array and is not resolved.

These libfiles are common library style files we use in our app that we don't want in node_modules. This is made possible by webpack's config.resolve.modules option:

resolve: {
    modules: {
        'node_modules',
        '_libs/' //this tells webpack to search in _libs for imports
    }
}

How can I get dependency-tree to understand my extra webpack modules?

First off, thanks for developing this great module! It was actually kind of difficult to find much options out there of being able to get a JS paths dependency tree, but this one worked wonders and not as limited as the requirejs optimizer.

What I'm trying to solve now is, during the build/test process of our app I'd like to be able to identify in the dependency tree paths to files that do not exist. From what it appears, dependency-tree (file-cabinet?) completely excludes paths to non-existent files from the output. I'd like to be able to detect for non-existent paths during our build/test process so we can to catch these errors in advance and not at runtime. Is there any way that dependency-tree can handle this somehow? Or is there another way/suggestions to achieve this?

Thanks!

I find .jsx file is supported in filling-cabinet by use jsLookup. but no vue

I want to get vue-project's dependency-tree want should i do?

I'm having trouble running this package over dependencies that include in index.tsx file as I'm getting the error:

tree skipping an empty filepath resolution for partial: components/lib +29ms

My index.tsx in components/lib just consists of export * from ___ lines.

I saw this similar issue here: pahen/madge#128 but it didn't seem to have a solution. Any ideas on this?

In the debug output i'm seeing:

 tree deduped list of nonExistent partials:  [ 
  'components/lib',
  ...
  '../..' ]

Refs dependents/node-precinct#49

Blocked until dependents/node-precinct#47 (comment) is resolved with main scoped require module resolution support in filing-cabinet.

• Bump precinct version
• When we have a fix in filing cabinet, bump its version
• Add a test here to make sure the file and its dependency gets added to the dependency tree