GithubHelp home page GithubHelp logo

dependents / node-dependency-tree Goto Github PK

View Code? Open in Web Editor NEW
648.0 8.0 80.0 906 KB

Get the dependency tree of a module

License: MIT License

JavaScript 100.00%
javascript dependency-tree ast es6 commonjs amd sass stylus tree typescript

node-dependency-tree's Introduction

dependency-tree

CI npm version npm downloads

Get the dependency tree of a module

npm install dependency-tree
  • Works for JS (AMD, CommonJS, ES6 modules), Typescript, and CSS preprocessors (CSS (PostCSS), Sass, Stylus, and Less); basically, any module type supported by Precinct.
    • For CommonJS modules, 3rd party dependencies (npm installed dependencies) are included in the tree by default
    • Dependency path resolutions are handled by filing-cabinet
    • Supports RequireJS and Webpack loaders
  • All core Node modules (assert, path, fs, etc) are removed from the dependency list by default

Usage

const dependencyTree = require('dependency-tree');

// Returns a dependency tree object for the given file
const tree = dependencyTree({
  filename: 'path/to/a/file',
  directory: 'path/to/all/files',
  requireConfig: 'path/to/requirejs/config', // optional
  webpackConfig: 'path/to/webpack/config', // optional
  tsConfig: 'path/to/typescript/config', // optional
  nodeModulesConfig: {
    entry: 'module'
  }, // optional
  filter: path => path.indexOf('node_modules') === -1, // optional
  nonExistent: [], // optional
  noTypeDefinitions: false // optional
});

// Returns a post-order traversal (list form) of the tree with duplicate sub-trees pruned.
// This is useful for bundling source files, because the list gives the concatenation order.
// Note: you can pass the same arguments as you would to dependencyTree()
const list = dependencyTree.toList({
  filename: 'path/to/a/file',
  directory: 'path/to/all/files'
});

Options

  • requireConfig: path to a requirejs config for AMD modules (allows for the result of aliased module paths)
  • webpackConfig: path to a webpack config for aliased modules
  • tsConfig: path to a typescript config (or a preloaded object representing the typescript config)
  • nodeModulesConfig: config for resolving entry file for node_modules
  • visited: object used for avoiding redundant subtree generations via memoization.
  • nonExistent: array used for storing the list of partial paths that do not exist
  • filter: a function used to determine if a module (and its subtree) should be included in the dependency tree
  • The first argument given to the filter is an absolute filepath to the dependency and the second is the filepath to the currently traversed file. Should return a Boolean. If it returns true, the module is included in the resulting tree.
  • detective: object with configuration specific to detectives used to find dependencies of a file
    • for example detective.amd.skipLazyLoaded: true tells the AMD detective to omit inner requires
    • See precinct's usage docs for the list of module types you can pass options to.
  • noTypeDefinitions: For TypeScript imports, whether to resolve to *.js instead of *.d.ts.

Format Details

The object form is a mapping of the dependency tree to the filesystem – where every key is an absolute filepath and the value is another object/subtree.

Example:

{
  '/Users/mrjoelkemp/Documents/node-dependency-tree/test/example/extended/a.js': {
    '/Users/mrjoelkemp/Documents/node-dependency-tree/test/example/extended/b.js': {
      '/Users/mrjoelkemp/Documents/node-dependency-tree/test/example/extended/d.js': {},
      '/Users/mrjoelkemp/Documents/node-dependency-tree/test/example/extended/e.js': {}
    },
    '/Users/mrjoelkemp/Documents/node-dependency-tree/test/example/extended/c.js': {
      '/Users/mrjoelkemp/Documents/node-dependency-tree/test/example/extended/f.js': {},
      '/Users/mrjoelkemp/Documents/node-dependency-tree/test/example/extended/g.js': {}
    }
  }
}

This structure was chosen to serve as a visual representation of the dependency tree for use in the Dependents plugin.

CLI version

  • Assumes a global install: npm install -g dependency-tree
dependency-tree --directory=path/to/all/supported/files [--list-form] [-c path/to/require/config] [-w path/to/webpack/config] filename

Prints the dependency tree of the given filename as stringified json (by default).

  • You can alternatively print out the list form one element per line using the --list-form option.

How does this work?

Dependency tree takes in a starting file, extracts its declared dependencies via precinct, resolves each of those dependencies to a file on the filesystem via filing-cabinet, then recursively performs those steps until there are no more dependencies to process.

In more detail, the starting file is passed to precinct to extract dependencies. Dependency-tree doesn't care about how to extract dependencies, so it delegates that work to precinct: which is a multi-language dependency extractor; we'll focus on JavaScript tree generation for this example. To do the extraction, precinct delegates the abstract-syntax-tree (AST) generation to the default parser for node-source-walk. Precinct uses the AST to determine what type of JS module the file is (Commonjs, AMD, or ES6) and then delegates to the "detective" that's appropriate for that module type. The "detective" contains the logic for how to extract dependencies based on the module syntax format; i.e., the way dependencies are declared in commonjs is different than in AMD (which has 4 ways of doing that, for example).

After using the detective to get the (raw, like './foobar') dependency strings, precinct passes that back to dependency-tree. Of course, in order to find the dependencies in './foobar', we need to resolve that dependency to a real file on the filesystem. To do this, dependency-tree delegates that task to filing-cabinet: which is a multi-language dependency resolver.

Filing-cabinet reuses (for performance) the AST that precinct made node-source-walk generate. It then does a similar check on the AST to see which module type (commonjs, amd, or es6) is being used in the file (again, we're assuming a regular JS file for this example) and then delegates to the appropriate resolver for that module type. We need different resolvers because a dependency name in AMD could be aliased via a requirejs config. Similarly, commonjs has its own algorithm for resolving dependencies.

So after the appropriate resolver finds the file on the filesystem, filing-cabinet has successfully mapped a raw dependency name to a file on the filesystem. Now, dependency-tree has a file that it can also traverse (repeating exactly what was done for the starting file).

At the end of traversing every file (in a depth-first fashion), we have a fully populated dependency tree. 👯

FAQ

Why aren't some some dependencies being detected?

If there are bugs in precinct or if the requireConfig/webpackConfig/tsConfig options are incomplete, some dependencies may not be resolved. The optional array passed to the nonExistent option will be populated with paths that could not be resolved. You can check this array to see where problems might exist.

You can also use the NODE_DEBUG=* env variable along with the cli version to see debugging information explaining where resolution went wrong. Example: NODE_DEBUG=* dependency-tree -w path/to/webpack.config.json path/to/a/file

node-dependency-tree's People

Contributors

antochiw avatar bpscott avatar dependabot[bot] avatar fauxfaux avatar igmdvc avatar irmantaszenkus avatar j-lee avatar jjangga0214 avatar jkemp-spotify avatar joscha avatar mrjoelkemp avatar nkjoep avatar pahen avatar pcardune avatar re-fort avatar realityking avatar tkohlman avatar vansosnin avatar xhmikosr avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

node-dependency-tree's Issues

how to support vue file?

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?

Post-Order Traversal

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.

Api changes

  • 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

dynamic import with Typescript doesn't work.

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': {},
  }
}

Get path to file

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

Support tsconfig (for typescript path aliases configuration)

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

Multiple lookup paths

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

Doesn't run without eslint installed

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.

i dont understand the directory option

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.

cli name conflicting with the popular tree

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

Trouble mixing typescript and javascript files

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.

JSON format

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

System js support

@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.

Memoization is incorrect

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.

line number

Hi,

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

Thank you

Drop required TypeScript dependency

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

webpack module resolution fails silently

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?

Windows bug

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

Problem with resolving absolute paths in AMD modules

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?

Unable to resolve index.tsx dependencies

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',
  ...
  '../..' ]

Bumping filing-cabinet version to 2.0.1

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.

Support webpack's config.resolve.modules paths

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?

Support for node style module resolution in Less

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.

Reverse dependency tree?

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

Support a filter function that determine whether or not to include a file in the tree

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.

How about support ES6 tree shaking

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']
  }]
}

Npm3 problems

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

image

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?

Support for exposing non-existent paths

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!

noTypeDefinitions usage

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.

npm i --global-style

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

Unable to resolve directory dependencies

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

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.