GithubHelp home page GithubHelp logo

depcheck / depcheck Goto Github PK

View Code? Open in Web Editor NEW
4.6K 24.0 224.0 2.09 MB

Check your npm module for unused dependencies

License: MIT License

JavaScript 98.61% CoffeeScript 0.03% TypeScript 0.53% Vue 0.46% Sass 0.11% SCSS 0.22% Svelte 0.03%

depcheck's Introduction

depcheck

Depcheck is a tool for analyzing the dependencies in a project to see: how each dependency is used, which dependencies are useless, and which dependencies are missing from package.json.

Status

Build Status Financial Contributors on Open Collective Build status codecov.io

Dependencies

Installation

npm install -g depcheck

Or simply using npx which is a package runner bundled in npm:

$ npx depcheck

Notice: depcheck needs node.js >= 10.

Syntax Support

Depcheck not only recognizes the dependencies in JavaScript files, but also supports these syntaxes:

To get the syntax support by external dependency, please install the corresponding package explicitly. For example, for TypeScript user, install depcheck with typescript package:

npm install -g depcheck typescript

Special

The special component is used to recognize the dependencies that are not generally used in the above syntax files. The following scenarios are supported by specials:

  • babel - Babel presets and plugins
  • bin - Dependencies used in npm commands, Travis scripts or other CI scripts
  • commitizen - Commitizen configuration adaptor
  • eslint - ESLint configuration presets, parsers and plugins
  • feross-standard - Feross standard format parser
  • gatsby - Gatsby configuration parser
  • gulp-load-plugins - Gulp-load-plugins lazy loaded plugins
  • husky - Husky configuration parser
  • istanbul - Istanbul nyc configuration extensions
  • jest - Jest properties in Jest Configuration
  • karma - Karma configuration frameworks, browsers, preprocessors and reporters
  • lint-staged - Lint-staged configuration parser
  • mocha - Mocha explicit required dependencies
  • prettier - Prettier configuration module
  • tslint - TSLint configuration presets, parsers and plugins
  • ttypescript - ttypescript transformers
  • webpack - Webpack loaders
  • serverless- Serverless plugins

The logic of a special is not perfect. There might be false alerts. If this happens, please open an issue for us.

Usage

depcheck [directory] [arguments]

The directory argument is the root directory of your project (where the package.json file is). If unspecified, defaults to current directory.

All of the arguments are optional:

--ignore-bin-package=[true|false]: A flag to indicate if depcheck ignores the packages containing bin entry. The default value is false.

--skip-missing=[true|false]: A flag to indicate if depcheck skips calculation of missing dependencies. The default value is false.

--json: Output results in JSON. When not specified, depcheck outputs in human friendly format.

--oneline: Output results as space separated string. Useful for copy/paste.

--ignores: A comma separated array containing package names to ignore. It can be glob expressions. Example, --ignores="eslint,babel-*".

--ignore-dirs: DEPRECATED, use ignore-patterns instead. A comma separated array containing directory names to ignore. Example, --ignore-dirs=dist,coverage.

--ignore-path: Path to a file with patterns describing files to ignore. Files must match the .gitignore spec. Example, --ignore-path=.eslintignore.

--ignore-patterns: Comma separated patterns describing files to ignore. Patterns must match the .gitignore spec. Example, --ignore-patterns=build/Release,dist,coverage,*.log.

--quiet: Suppress the "No depcheck issue" log. Useful in a monorepo with multiple packages to focus only on packages with issues.

--help: Show the help message.

--parsers, --detectors and --specials: These arguments are for advanced usage. They provide an easy way to customize the file parser and dependency detection. Check the pluggable design document for more information.

--config=[filename]: An external configuration file (see below).

Usage with a configuration file

Depcheck can be used with an rc configuration file. In order to do so, create a .depcheckrc file in your project's package.json folder, and set the CLI keys in YAML, JSON, and JavaScript formats. For example, the CLI arguments --ignores="eslint,babel-*" --skip-missing=true would turn into:

.depcheckrc

ignores: ["eslint", "babel-*"]
skip-missing: true

Important: if provided CLI arguments conflict with configuration file ones, the CLI ones will take precedence over the rc file ones.

The rc configuration file can also contain the following extensions: .json, .yaml, .yml.

API

Similar options are provided to depcheck function for programming:

import depcheck from 'depcheck';

const options = {
  ignoreBinPackage: false, // ignore the packages with bin entry
  skipMissing: false, // skip calculation of missing dependencies
  ignorePatterns: [
    // files matching these patterns will be ignored
    'sandbox',
    'dist',
    'bower_components',
  ],
  ignoreMatches: [
    // ignore dependencies that matches these globs
    'grunt-*',
  ],
  parsers: {
    // the target parsers
    '**/*.js': depcheck.parser.es6,
    '**/*.jsx': depcheck.parser.jsx,
  },
  detectors: [
    // the target detectors
    depcheck.detector.requireCallExpression,
    depcheck.detector.importDeclaration,
  ],
  specials: [
    // the target special parsers
    depcheck.special.eslint,
    depcheck.special.webpack,
  ],
  package: {
    // may specify dependencies instead of parsing package.json
    dependencies: {
      lodash: '^4.17.15',
    },
    devDependencies: {
      eslint: '^6.6.0',
    },
    peerDependencies: {},
    optionalDependencies: {},
  },
};

depcheck('/path/to/your/project', options).then((unused) => {
  console.log(unused.dependencies); // an array containing the unused dependencies
  console.log(unused.devDependencies); // an array containing the unused devDependencies
  console.log(unused.missing); // a lookup containing the dependencies missing in `package.json` and where they are used
  console.log(unused.using); // a lookup indicating each dependency is used by which files
  console.log(unused.invalidFiles); // files that cannot access or parse
  console.log(unused.invalidDirs); // directories that cannot access
});

Example

The following example checks the dependencies under /path/to/my/project folder:

$> depcheck /path/to/my/project
Unused dependencies
* underscore
Unused devDependencies
* jasmine
Missing dependencies
* lodash

It figures out:

  • The dependency underscore is declared in the package.json file, but not used by any code.
  • The devDependency jasmine is declared in the package.json file, but not used by any code.
  • The dependency lodash is used somewhere in the code, but not declared in the package.json file.

Please note that, if a subfolder has a package.json file, it is considered another project and should be checked with another depcheck command.

The following example checks the same project, however, outputs as a JSON blob. Depcheck's JSON output is in one single line for easy pipe and computation. The json command after the pipe is a node.js program to beautify the output.

$> depcheck /path/to/my/project --json | json
{
  "dependencies": [
    "underscore"
  ],
  "devDependencies": [
    "jasmine"
  ],
  "missing": {
    "lodash": [
      "/path/to/my/project/file.using.lodash.js"
    ]
  },
  "using": {
    "react": [
      "/path/to/my/project/file.using.react.jsx",
      "/path/to/my/project/another.file.using.react.jsx"
    ],
    "lodash": [
      "/path/to/my/project/file.using.lodash.js"
    ]
  },
  "invalidFiles": {
    "/path/to/my/project/file.having.syntax.error.js": "SyntaxError: <call stack here>"
  },
  "invalidDirs": {
    "/path/to/my/project/folder/without/permission": "Error: EACCES, <call stack here>"
  }
}
  • The dependencies, devDependencies and missing properties have the same meanings in the previous example.
  • The using property is a lookup indicating each dependency is used by which files.
  • The value of missing and using lookup is an array. It means the dependency may be used by many files.
  • The invalidFiles property contains the files having syntax error or permission error. The value is the error details. However, only one error is stored in the lookup.
  • The invalidDirs property contains the directories having permission error. The value is the error details.

False Alert

Depcheck just walks through all files and tries to find the dependencies according to some predefined rules. However, the predefined rules may not be enough or may even be wrong.

There may be some cases in which a dependency is being used but is reported as unused, or a dependency is not used but is reported as missing. These are false alert situations.

If you find that depcheck is reporting a false alert, please open an issue with the following information to let us know:

  • The output from depcheck --json command. Beautified JSON is better.
  • Which dependencies are considered as false alert?
  • How are you using those dependencies, what do the files look like?

Changelog

We use the GitHub release page to manage changelog.

Contributors

Code Contributors

This project exists thanks to all the people who contribute. [Contribute].

Financial Contributors

Become a financial contributor and help us sustain our community. [Contribute]

Individuals

Organizations

Support this project with your organization. Your logo will show up here with a link to your website. [Contribute]

License

MIT License.

depcheck's People

Contributors

43081j avatar aleung avatar dependabot-preview[bot] avatar dev-goformative avatar devan1011 avatar dobesv avatar dword-design avatar dylang avatar gmeligio avatar goloroden avatar kaboomfox avatar legobeat avatar lijunle avatar linusu avatar miluoshi avatar mnkhouri avatar nagygergo avatar oligot avatar pouya-eghbali avatar rjatkins avatar rumpl avatar shian15810 avatar sudo-suhas avatar sveyret avatar urik avatar vincentlanglet avatar winniehell avatar woodb avatar yonatankra avatar znarf 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  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

depcheck's Issues

ES6 support?

Hi, and first of all thanks for a great piece of code.

Have you considered adding support for ES6 files โ€“ run via babel or traceur?

It should be as simple as looking for import .+ from "<dependency>(/.+)?"; as well as require\("<dependency>(/.+)?"\);.

Find dependencies which aren't listed in package.json

I know it's kind of the inverse of what it does right now, but I was just wondering if you'd be open to having this kind of functionality added to depcheck.

There is a separate tool that already does this (dependency-check), but it doesn't support ES6 syntax yet. Depcheck may have better infrastructure ready to cover both cases.

And by the way - this is a great tool, thanks for all your work on it.

add support for files with a node shebang

depcheck doesn't appear to take into account files without a .js extension but that contain a node shebang (eg #!/usr/bin/env node). Example:

$ tree -L 1
.
โ”œโ”€โ”€ executable
โ”œโ”€โ”€ node_modules
โ””โ”€โ”€ package.json

1 directory, 2 files

$ cat package.json
{
    "dependencies": {
        "through": "latest"
    }
}

$ cat executable
#!/usr/bin/env node
var through = require("through");

$ depcheck
Unused Dependencies
* through

Renaming executable to executable.js resolves the problem, though.

doesn't work with CSS dependencies

package.json:

"dependencies": {
  "bootstrap-sass": "^3.3.6",
  "font-awesome": "^4.5.0",
}

styles.scss:

@import "node_modules/bootstrap-sass/assets/stylesheets/bootstrap";
@import "node_modules/font-awesome/scss/font-awesome.scss";

depcheck:

Unused Dependencies
* bootstrap-sass
* font-awesome

Performance debug parameter

Proposal with --debug-performance parameter, it calculates how much time on each file for process (parse, detect). With such information, we can find out where the bottleneck is.

  • Local performance debugging
  • Test and CI for performance
  • Custom real time performance debug parameter
  • Others?

Reference: #100

Performance enhancement

From @lijunle on September 26, 2015 14:28

Currently, depCheck looks for all files under directory to get dependency result.

Some strategies can be used to optimize the performance:

  1. First, it get packages from a part of files, compare with declaring packages.
  2. If all declaring packages are used, stop reading files. Return everything is good. โœ…
  3. If not all declaring packages are used, continue the step 1.
  4. If all files are searched, but there are some declaring packaged not fulfilled, show them as unused. โŒ

Concretely, it need to convert the promise queue in checkDirectory to Array<Func<Promise>> queue. The promises are triggered only then function is invoked.

Copied from original issue: lijunle#49

support for multiple entry points

seems like it detects all my client-side dependences as unused as they have a different entry point which isn't defined in main. also, our grunt dependencies are not included either. can we have an option to manually input multiple entry points?

option to ignore directories

Right now depcheck walks every directory except node_modules

finder.on("directory", function (dir) {
    if (path.basename(dir) === "node_modules") {
      return;
    }
    directories.push(dir);
  });

It would be helpful if we could provide an array of directories to ignore so we could avoid scanning our build directory which happens to be huge.

For example

depcheck(root, {
    ignoreDirs: [ 
        // node_modules is assumed
        'build',
        'bower_components'
    ]  
    }, cb);

don't change string prototype

if (typeof String.prototype.startsWith !== "function") {
  String.prototype.startsWith = function (str) {
    return this.slice(0, str.length) === str;
  };
}

This means you are changing how string works for all code that depends on your code.

It would be prefered to use a function or something like underscore.string. https://github.com/epeli/underscore.string

I'm not sure if this is related, but a co-worker is seeing this:

depcheck/index.js:95
      if (usedDependency === definedDependency || usedDependency.startsWith(de
                                                                 ^
TypeError: Object 11 has no method 'startsWith'
    at node_modules/npm-check/node_modules/depcheck/index.js:95:66

Depcheck is busted

โฏ depcheck myapp

/usr/local/lib/node_modules/depcheck/node_modules/detective/node_modules/esprima-fb/esprima.js:6268
            throw e;
                  ^
Error: Line 51663: Invalid regular expression
    at throwError (/usr/local/lib/node_modules/depcheck/node_modules/detective/node_modules/esprima-fb/esprima.js:2159:21)
    at scanRegExp (/usr/local/lib/node_modules/depcheck/node_modules/detective/node_modules/esprima-fb/esprima.js:1343:13)
    at parsePrimaryExpression (/usr/local/lib/node_modules/depcheck/node_modules/detective/node_modules/esprima-fb/esprima.js:2665:43)
    at parseLeftHandSideExpressionAllowCall (/usr/local/lib/node_modules/depcheck/node_modules/detective/node_modules/esprima-fb/esprima.js:2755:61)
    at parsePostfixExpression (/usr/local/lib/node_modules/depcheck/node_modules/detective/node_modules/esprima-fb/esprima.js:2795:20)
    at parseUnaryExpression (/usr/local/lib/node_modules/depcheck/node_modules/detective/node_modules/esprima-fb/esprima.js:2859:16)
    at parseBinaryExpression (/usr/local/lib/node_modules/depcheck/node_modules/detective/node_modules/esprima-fb/esprima.js:2947:16)
    at parseConditionalExpression (/usr/local/lib/node_modules/depcheck/node_modules/detective/node_modules/esprima-fb/esprima.js:2994:16)
    at parseAssignmentExpression (/usr/local/lib/node_modules/depcheck/node_modules/detective/node_modules/esprima-fb/esprima.js:3179:16)
    at parseSpreadOrAssignmentExpression (/usr/local/lib/node_modules/depcheck/node_modules/detective/node_modules/esprima-fb/esprima.js:2711:16)
    at parseArguments (/usr/local/lib/node_modules/depcheck/node_modules/detective/node_modules/esprima-fb/esprima.js:2688:23)
    at parseLeftHandSideExpressionAllowCall (/usr/local/lib/node_modules/depcheck/node_modules/detective/node_modules/esprima-fb/esprima.js:2759:24)

Bug with subdirectories?

I'm running into an issue where files in subdirectories aren't correctly checked (at least for peerDependancies) for require statements

Quick test:

./package.json and npm install

{
  "name": "test-dep",
  "version": "1.0.0",
  "description": "test peerdeps",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "author": "",
  "license": "ISC",
  "devDependencies": {
    "css-modules-require-hook": "^2.1.0",
    "postcss-modules-extract-imports": "^1.0.0",
    "postcss-modules-local-by-default": "^1.0.0",
    "postcss-modules-scope": "^1.0.0",
    "postcss-modules-values": "^1.1.1"
  }
}

./entry.js

require('css-modules-require-hook');

Running depcheck:

No unused dependencies

Working as intended

Breaks:

make a folder test/ and move entry.js there:

$ mkdir test && mv entry.js test

Running depcheck:

Unused devDependencies

  • postcss-modules-extract-imports
  • postcss-modules-local-by-default
  • postcss-modules-scope
  • postcss-modules-values

Debug info:

$ npm --version
3.3.12
$ node --version
v5.1.0

depcheck is latest installed with npm install -g depcheck


Is this desired behavior? Quick look at the folder scanning, it seems to be going into (sub)directories unless they're ignored.

Support for commitizen modules

Commitizen is a tool for enforcing style of git commit messages, it's quite useful. However, npm-check is giving me a hard time about unused dependencies.

test-cz       ๐Ÿ˜•  NOTUSED?  Possibly never referenced in the code.
                            npm uninstall --save-dev test-cz to remove.

My package.json looks like this:

{
  "devDependencies": {
    "test-cz": "^0.1.0"
  },
  "config": {
    "commitizen": {
      "path": "./node_modules/test-cz"
    }
  }

Webpack loader support

From @lijunle on September 19, 2015 21:20

Webpack loaders are a special way to "load" code into webpack.

There are two syntax to use webpack loader:

  • Via require function
  • Via webpack config file

Copied from original issue: lijunle#14


There are several syntaxes about Webpack loaders:

  • The require calls. (example) [3]
  • CLI --module-bind options. (example) [2]
  • Configuration properties.
    • Single loader in module.loaders.loader string (example) [1]
    • Multiple loaders concatenated with ! in module.loaders.loader string (example) [1]
    • Multiple loaders in module.loaders.loaders array (example) [1]
    • Loader with queries in module.loaders.loader string (example) [1]

Other considerations about loader:

Notes:

  • The items marked as [1] will be implemented and supported.
  • The items marked as [2] will be supported with the default values. If someone request and provide his meaningful scenario, open an issue and let us how to support it.
  • The items marked as [3] are considered as not supported. If you think they are necessary and have a good reason, please open an issue.

vice versa function

From @js08 on October 28, 2015 18:20

Is it possble to identify the package name in package.json file when that module is not present. I mean can we do a vice versa function in depcheck-es6

Copied from original issue: lijunle#99

eslint support issues

.eslintrc

....
  "extends": [
    "react",
    "eslint:recommended"
  ],
  "parser": "babel-eslint",
  "plugins": [
    "react"
  ],
....

run results:

develop@develop-vm ~/Projects/project (master*) $ depcheck                       

Unused devDependencies
* babel-eslint
* eslint-config-react
* eslint-plugin-react

It does not seem to depend on the correct handling of devDependencies?

dead project?

Is this project dead? I see some pull requests asking for feedback from the maintainer but no follow up.

bump to 1.0.0 for semver support

Not a bug, just a friendly request. ๐Ÿ˜„

By bumping to 1.0.0 it means minor and patch releases are backwards compatible and projects that depend on depcheck like npm-check can easily upgrade.

If you think the API is not stable enough for a 1.0.0 I still wouldn't worry. I personally don't mind frequent major bumps - it tells me the API is evolving and that's great too. Browserify is on version 13.x.y.

On a totally different note, I just noticed the release notes with each deploy, thank you for taking the time to do this! I wish I could be as disciplined.

Allow to define patterns against absolute file path

First of all it's a great tool and I wanted to integrate it into my project, though the use case of mine is a little bit different how you prefer to use it. Acutally I wanted to parse only a specific file list within the root directory so ignoring dirs doesn't help.

Reading the codebase I realised that I have another option, namely I can define parsers for patterns which is a cool a feature though it cannot be used for my use case, at least not for now.

Let's assume that we have two JS files within the src folder, and I want to use this pattern:
src/*.js

Currently it does not work as you get the basename from the absolute path of the file.
line 124 in check.js:
const basename = path.basename(filename);
This prevents to use a prefix pattern for the absolute path like mentioned before.

Can you please omit the basename call and pass the filename to the minimatch?

Thank you for fixing this.

dependency-check comparison

crazy timing, i went to go publish this today https://github.com/maxogden/dependency-check and found out you picked the same name 4 days ago! haha! I just renamed it to dependency-check instead

my use case was to do a consistency check before I publish a module to make sure all of the modules used are listed in the package.json. that way I can have dependency-check run as a pre-publish hook and since it does process.exit(1) if it find missing deps it should halt the publish

feel free to close this, I mostly just wanted to comment on the funny coincidence

Add scenario test infrastructure.

Currently, I manually setup an environment with yoeman and yoeman-web-app to test depcheck on it. We should automate the process and integrate it into CI build.

ReferenceError: Promise is not defined

Using node v0.10.38. All I did was npm install -g depcheck and try to run it. I need to remember where Promise comes from, but seems like depcheck's package.json dependencies is incomplete.

>>$ depcheck 

/home/colbblai/.nvm/v0.10.38/lib/node_modules/depcheck/dist/cli.js:39
  return new Promise(function (resolve, reject) {
             ^
ReferenceError: Promise is not defined
    at checkPathExist (/home/colbblai/.nvm/v0.10.38/lib/node_modules/depcheck/dist/cli.js:39:14)
    at /home/colbblai/.nvm/v0.10.38/lib/node_modules/depcheck/dist/cli.js:87:7
    at cli (/home/colbblai/.nvm/v0.10.38/lib/node_modules/depcheck/dist/cli.js:113:7)
    at Object.<anonymous> (/home/colbblai/.nvm/v0.10.38/lib/node_modules/depcheck/bin/depcheck:5:23)
    at Module._compile (module.js:456:26)
    at Object.Module._extensions..js (module.js:474:10)
    at Module.load (module.js:356:32)
    at Function.Module._load (module.js:312:12)
    at Function.Module.runMain (module.js:497:10)
    at startup (node.js:119:16)

depcheck should accept metadata from options

I think that depcheck should accept package.json metadata from the options, so we could use it dynamically.

var path = require("path");
var depcheck = require("depcheck");
var options = {
  "withoutDev": false, // Check against devDependencies too
  "package": {
    "dependencies": {
      "express": "^4.0.0"
    }
  },
  "ignoreDirs": [      // Pathnames to ignore
    "sandbox",
    "dist",
    "bower_components"
  ],
  "ignoreMatches": [  // Ignore dependencies that match these minimatch patterns
    "grunt-*"
  ]
};
var root = path.resolve("some path");

depcheck(root, options, function(unused) {
  console.log(unused.dependencies);
  console.log(unused.devDependencies);
  console.log(unused.invalidFiles); // JS files that couldn't be parsed
});

Question: Gulp support?

Hi there,

I'm looking for a Gulp support for addressing this problem... Have you integrated your app to Gulp or Grunt? Any suggestions? I can submit a PR if there's interest...

thanks!

False Positives with gulp-load-plugins && gulp-jshint

Hello,

Was looking around at how to determine un-used npm packages and found your project.

When I ran it the following report was generated. However, due to the way I'm loading gulp plugins (using gulp-load-plugins, my guess is this tool is not picking up anything that is dynamically loaded. Similarly, I'm asking it to use the jshint-stylish reporter for my jshint, which I presume is another dynamically loaded thing...

Unused Dependencies
* gulp-debug

Unused devDependencies
* gulp-markdown
* gulp-mocha
* gulp-plumber
* gulp-jshint
* gulp-jscs
* jshint-stylish
* gulp-istanbul

I can't say I have any bright ideas on how you can solve these problems, but in case you hadn't heard of them, they might be interesting ones to look into.

Find a solution to declare peer dependencies

npm@2 is installing the peer dependencies which is an unexpected behavior, as they are optional for depcheck, and this means when using npm@2, they are always installed.

npm@3 won't install them, but gives unexpected warnings:

โ”œโ”€โ”€ UNMET PEER DEPENDENCY node-sass@^3.4.0
โ””โ”€โ”€ UNMET PEER DEPENDENCY typescript@^1.8.0

npm WARN [email protected] requires a peer of node-sass@^3.4.0 but none was installed.
npm WARN [email protected] requires a peer of typescript@^1.8.0 but none was installed.

I feel like the feature of using the dependencies when they are available is great, but instead of including them as peer dependencies, just include instructions in the docs what users need to do.

Support for coffee?

How difficult would it be to add coffee-script support so that the "unused" checks are accurate in coffee projects?

includeDirs

Enhancement:

To compliment your ignoreDirs how about includeDirs? Default is all directories below the cwd or a given path if not used. Otherwise just the array of given includeDirs.

In a project typically I would have only one or two directories I want checked. Using ignoreDirs I must specify a longer list of directories that changes and is thus harder to maintain.

Seems like maybe you aren't doing much with this repo at this time. I might eventually get around to a PR for this.

Error: toString failed

Error: toString failed when used with node v4.3.1

$ depcheck

buffer.js:388
    throw new Error('toString failed');
    ^

Error: toString failed
    at Buffer.toString (buffer.js:388:11)
    at FSReqWrap.readFileAfterClose [as oncomplete] (fs.js:378:21)

Babel plugin support

From @lijunle on October 26, 2015 19:29

In .babelrc:

{
  "stage": 2,
  "env": {
    "development": {
      "plugins": [
        "react-transform"
      ],
      "extra": {
        "react-transform": {
          "transforms": [{
            "transform": "react-transform-hmr",
            "imports": ["react"],
            "locals":  ["module"]
          }]
        }
      }
    }
  }
}

Expected packages:

  • babel-plugin-react-transform
  • react-transform-hmr

Work items:

  • The configs in .babelrc file.
  • Configs with options (example).
  • The configs in envionment (example).
  • The configs in package.json (example).
  • The configs in Babel CLI. (see note below)
  • The configs in API calls. (see note below)

Note: It need more affect to support Babel plugins in CLI and API calls. They are not recommended by Babel. Please open an issue and let me know the reason if anybody think they are necessary.

Copied from original issue: lijunle#97

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.