escomplex / escomplex Goto Github PK

Version 3.4.0 of mocha just got published.

This version is covered by your current version range and after updating it in your project the build failed.

As mocha is “only” a devDependency of this project it might not break production or downstream projects, but “only” your build or test tools – preventing new deploys or publishes.

I recommend you give this issue a high priority. I’m sure you can resolve this 💪

Your Greenkeeper Bot 🌴

Is it right, that the ArrayExpression operands is at all time <anonymous>?

The EsTree Syntax says that there is not an attribute 'name' on this object.
see Spec

The top-level interface for this package now includes three methods:

• analyse
• analyseModule
• analyseProject

Update the README.md to document each of these, and provide docs/examples of using a custom parser.

  escomplex Custom parse function +0ms
  escomplex Parsed AST:  +7s
/__CENSORED__/node_modules/escomplex/src/index.js:36
  debug(JSON.stringify(ast, null, 2))
             ^

RangeError: Invalid string length
    at join (native)
    at Object.stringify (native)
    at Object.module.exports.analyse (/__CENSORED__/node_modules/escomplex/src/index.js:36:14)
    at nextFile (/__CENSORED__/bin/development/complexity-summary.js:58:44)
    at onFileProcessed (/__CENSORED__/bin/development/complexity-summary.js:80:7)
    at onFileRead (/__CENSORED__/bin/development/complexity-summary.js:49:5)
    at FSReqWrap.readFileAfterClose [as oncomplete] (fs.js:380:3)

JSON.stringify(ast, null, 2) is executed unconditionally causing the whole analysis to fail even if I don't enable the debug output.

In an effort to simpify the care and feeding of the escomplex projects, this project will absorb the code and functionality of the follow projects:

• escomplex-js
• escomplex-ast-moz
• escomplex-traits

The details of this change are documented here

Update the project to adhere to the JavaScript Standard Style.

This involves:

1. Updating the contribution docs to explain that we are using this style.
2. Incorporating the standard module into the test script in package.json.
3. Updating all source to adhere to the constraints of the standard style.

Updating dependency spooks from 0.5.x to 2.0.x results in some test failures:

635 passing (819ms)
61 pending
6 failing

1. index: require: array source: core.analyse was given correct asts:
   AssertionError: expected undefined to equal 'esprima.parse result'
   at Function.assert.strictEqual (node_modules/chai/lib/chai/interface/assert.js:178:32)
   at Context. (test/index.js:143:24)

2. index: require: array source: correct result was returned:
   AssertionError: expected undefined to equal 'core.analyse result'
   at Function.assert.strictEqual (node_modules/chai/lib/chai/interface/assert.js:178:32)
   at Context. (test/index.js:161:24)

3. index: require: string source: core.analyse was given correct ast:
   AssertionError: expected undefined to equal 'esprima.parse result'
   at Function.assert.strictEqual (node_modules/chai/lib/chai/interface/assert.js:178:32)
   at Context. (test/index.js:231:24)

4. index: require: string source: correct result was returned:
   AssertionError: expected undefined to equal 'core.analyse result'
   at Function.assert.strictEqual (node_modules/chai/lib/chai/interface/assert.js:178:32)
   at Context. (test/index.js:243:24)

5. index: require: string arguments: operators was correct:
   AssertionError: expected undefined to equal 'operators result'
   at Function.assert.strictEqual (node_modules/chai/lib/chai/interface/assert.js:178:32)
   at Context. (test/traits.js:127:24)

6. index: require: string arguments: operands was correct:
   AssertionError: expected undefined to equal 'operands result'
   at Function.assert.strictEqual (node_modules/chai/lib/chai/interface/assert.js:178:32)
   at Context. (test/traits.js:131:24)

In order to maintain modern language support, we need better feedback about how escomplex integrates (or doesn't) with the most common parsers. Consequently, the current set of syntax tests should be updated to run against the following list of parsers:

• Esprima
• Espree
• Acorn
• Babylon

do you have a plan to support es6?

Hi Jared,
I'm building a tool to capture and analyse source code complexity and I've been happily using escomplex as far as javascript is concerned. Unfortunately some of the projects I've been testing my tool against have started adopting es6 and React with JSX, and that obviously is creating some problems.

I'd like to describe the two main problems I've been trying to work around before you agree to actually open a new issue for escomplex.

The first problem I have is that some of the projects are migrating from old legacy javascript to the new ES6, where that their frontend code is a mix of old and new javascript code. That means that I need to be able to parse it either with sourceType = 'script' or sourceType = 'module'. Unfortunately I don't see a way to pass specific esprima options to the escomplex.analyse function, so I resorted to bypass its natural facade by directly parsing the files with esprima and then invoking the analyse function in the escomplex/src/core module. I don't think this is a long term viable option as you may want to change your core module interface in the future.

The second problem I have is supporting non standard javascript features, like JSX in React for example.
I read in your post "The Next Version of ESComplex" that you're planning to support any parser that complies with the EStree specification, and I'm asking you when you think that may happen. I'm happy to offer help if you need it. At the moment again I resolved my problem by parsing the files with acorn, that has a plugin for JSX and produces a valid AST, and then again analysing the tree with escomplex core, but, as I said earlier, that feels more like a temporary workaround.

Thanks

Reposted from https://github.com/jared-stilwell/escomplex-ast-moz/issues/88

Whenever I run the following code:

const file = fs.readFileSync(filePath);
const ast = esprima.parse(file, {range: true, comment: true});
const escomplexResult = escomplex.analyse(ast, escomplexWalker);

an the code has CallExpressions I get the following error: http://imgur.com/xTcEDzN

This code was previously working for me

This fixed the issue :

const ast = esprima.parse(file, {loc: true, range: true, comment: true});

The indication that the walker needs the loc option should be indicated.

This repository is now unmaintained. If you are interested in assuming maintainership, please comment on this issue or email me directly.

Into index.js is used esprima (line 5):

var esprima = require('esprima');

But this package is installed only as devDependencies on package.json:

"devDependencies": { "chai": "^3.4.1", "eslint": "^2.2.0", "esprima": "^2.7.1", "mocha": "^2.3.4", "mockery": "1.4.x", "sinon": "^1.16.1", "spooks": "0.5.x" },

As a result, the escomplex package cannot be use with a simple:

npm install escompex

Having all the syntax definitions reside in individual modules definitely works, but it becomes cumbersome pretty quickly to hop between files when making significant changes.

Instead, refactor the syntax definitions for the ES5 spec and below into a single module. Likewise, factor any ES6 language features into a single module. This will make the support levels for the ES6+ spec much more explicit in the file structure and should ease the process toward full compatibility with future language specs.

In order to avoid confusion among American English-speakers, the top-level API of escomplex should include a function analyze that is an alias to the analyse function.

The README.md also needs to be cleaned up a bit. It contains typos where analyze should really be analyse instead. The references in the README.md and other documentation should still be analyse going forward. This alias is simply a safety mechanism so that consumers can still "misspell" the function name and have it just work.

Update author references in:

• package.json
• CONTRIBUTING.md
• AUTHORS
• COPYING

Version 5.6.1 of acorn was just published.

This version is covered by your current version range and after updating it in your project the build failed.

acorn is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

Currently, the test code is being included in the escomplex package once its installed via npm. Add the test directory to the .npmignore to keep them out of the installed package.

As an initial step toward providing support for modern language features, the public API for the module needs to be updated. A third argument should be introduced to the analyse function that can either be an object or a function.

If the third argument is provided as an object, it should be treated as an override to the options passed to the default parser (esprima at the time of writing). Nodes in the resulting abstract syntax tree (AST) are required to be annotated with location in order for the reporting to be accurate. Consequently, the loc option should be hard-set to true.

If the third argument is provided as a function, it should be treated as a callback which accepts source code as a string and returns an AST.

The hoodie contributing docs are second to none. Steal as much as you can from them, while respecting the project license.

Additional goals:

• Establish a code of conduct for all communication within the project.
• Be clear about what contributors should expect. Talk about the process from contribution through review and acceptance.
• Be explicit about what is and is not acceptable in terms of code quality, coverage, or style.
• Offer tips for making the submissions easier to accept.

Hi,

in the maintainability process there is a percentage calculation if the settings newmi is set. But what is the meaning of newmi?

Thanks for maintaining a helpful JavaScript metrics project.

One of the metrics you offer, the "Maintainability Index", however, is an outdated metric that has some serious problems. There are several research papers essentially drawing this conclusion. I have summarized these papers in a blog post Think Twice Before Using the “Maintainability Index”.

Maybe it would be useful to add a pointer to this blog post in your Links to Research section in your README? If you agree, let me know and I can create a pull request.

(Some of my students are happily using escomplex, but then unfortunately also draw unjustified conclusions based on the "Maintainability Index". A warning might help.)

Update the dependencies and dev-dependencies in package.json based on the david-dm status.

Add dependencies (http://david-dm.org/jared-stilwell/escomplex.svg) and dev-dependencies (http://david-dm.org/jared-stilwell/escomplex/dev-status.svg) badges to README.md

See attached complexity report and test inputs. It looks like complexity report (and likely the underlying escomplex) doesn't see code within ES6 classes. The sample (es6classtest3.js) has a class containing one function, and that doesn't show up in the complexity report (cr.txt). A control sample without a class (es6classtest2.js) is analyzed correctly.

I tested with complexity-report 2.0.0-alpha - since the underlying issue is in escomplex, I'm reporting it here as well as suggested by @jared-stilwell - his comments are below:

There are essentially two limiting factors here. The first is Esprima's support for parsing ES6 into an AST that complies with the ESTree spec. While Esprima has already implemented support for parsing ES6 classes, the escomplex module does not yet have support for processing the resulting AST nodes.

In short, once support for ES6 classes makes it into escomplex, then your classes should show up in the complexity report. Please open an issue on the escomplex project to support ES6 classes and I'll prioritize this accordingly.

@jared-stilwell (and contributors) thanks for taking on maintaining escomplex. I'd certainly like to integrate it with ESDoc as a plugin in addition to using D3 for interactive graphs of the data generated. I've already done basic integration tests and here are my thoughts (hopefully this isn't a bit presumptuous).

I'd just like to know your intentions (I've read your blog posts) for escomplex and if you can see yourself and others working on it to get it up to production standards? I'd be glad to help out in this regard or simply fork what you have as the skeleton framework is here. I'd prefer to collaborate / contribute if possible. The velocity is quite slow and unclear if there are intentions to make a production ready release on the horizon.

From one of your blog posts...

We'll continue using Esprima and set a goal to support any parser that complies with the EStree specification.

As it stands currently Esprima is a "surface" dependency (though not added in the package.json!) for escomplex I do recommend splitting off all of the AST processing to escomplex-core. And leave escomplex to just the index.js. Esprima is only used in index.js to generate the AST and is an unnecessary dependency for integration where parsing is already handled.

The reason being is that Espree is also a common ESTree based parser and is the one used in ESDoc and AST is already generated in ESDoc which can easily be sent to the core functionality of escomplex.

Here is the simple test integration I've made which outputs escomplex reports for every file processed by ESDoc (this is ES6 code too as espree is configured for ES6):
esdoc-plugin-escomplex/src/analyse.js
esdoc-plugin-escomplex/src/plugin.js

The main reason ES6 code is not parsed by escomplex right now is because incomplete options are being fed to esprima. If esprima is anything like espree too you have to vary the options depending on code being processed.

Of course the AST import directives are not being processed by escomplex and such. I can certainly help add the ES6 AST processing as I've been working a lot with ES6 AST recently.

Other small comments if you move forward I suggest creating a Github organization for escomplex and related repos. It makes it a lot easier to organize collaborators.

If there is a chance that you don't see yourself and others getting a production version together that supports ES6 anytime soon let me know. I'd be glad to setup a Github organization and just get it done as a production version shouldn't take more than 3 days effort if that. Again a bit presumptuous on my part.

The version is on npm is 2.0.0.alpha, which is the same as current one on GitHub.

However this is misleading, because the version published on npm is from this commit, which is 18 months and about 50 commits old.

Possible suggestions:

• upgrading version to 2.0.0
• publishing to npm
• introduce more frequent version upgrading and publishing

The .gitattributes file in the root of the repo isn't serving any discernible purpose. Let's get rid of it.

The nilHalsteadMetrics() method is only called on line 289 module.js. This logic can be moved inline.

e.g.

...
function calculateHalsteadMetrics (data) {
  data.length = data.operators.total + data.operands.total;
  if (data.length === 0) {
    data.vocabulary = 0;
    data.difficulty = 0;
    data.volume = 0;
    data.effort = 0;
    data.time = 0;
    data.bugs = 0;
  } else {
...

Greets @jared-stilwell et al,

I just finished a significant refactor of escomplex that fully supports ES6 along with acorn, espree, esprima generated AST. (edit: and ES7 / all babylon features!)

Edit: you can read the rest of this issue / thread and learn that my refactor was not accepted by @jared-stilwell for reasons, however I now have a fully published next generation version of escomplex available here:
https://www.npmjs.com/package/typhonjs-escomplex
https://www.npmjs.com/package/typhonjs-escomplex-module
https://www.npmjs.com/package/typhonjs-escomplex-project

This new refactor is modular and uses a plugin architecture for easy extension and will see several feature enhancements in short order. Please review all modules available at the typhonjs-node-escomplex organization. Cheers...

I split off all AST processing to escomplex-core and removed all external dependencies including node so escomplex-core can be used anywhere including the browser.

escomplex has the same API, but I switched things to espree as it's a way better parser than esprima and conformant to the ESTree spec which esprima is not.

Don't fret though as I resolved all of the issues in supporting acorn / espree / esprima and escomplex-core runs all test suites against these 3 parsers. I also added a thorough test suite for ES6 which is almost twice as large as the core module test suite.

For now you can use the following in package.json to test things out:

  "dependencies": {
    "escomplex": "git+https://[email protected]/typhonjs-node-escomplex/escomplex.git",
  },

or just for the core AST processing:

  "dependencies": {
    "escomplex-core": "git+https://[email protected]/typhonjs-node-escomplex/escomplex-core.git",
  },

@jared-stilwell I'd be glad to do a PR once you get to check things out.

In order to pick up new versions of Node.js as they are released, add "stable" to the list of node versions to run against.

Currently, the escomplex module exports a single function: analyse.

The behavior of the the analyse function changes implicitly based on the first argument passed to it. When it is passed a string code source, analysis is performed on the single source module and a single report object is returned.

If an array is passed as the first argument, we assume each item in the array is an object with the string properties path and code. In this case a report object or aggregate metrics is returned. The aggregate report object also contains the the reports property with a collection of the individual reports indexed parallel to the collection of sources originally passed as the first argument.

Cramming both the module case (i.e. a single code source) and the project case (i.e. a collection of sources with path information) into the same function overly complicates the internals. It is a more direct expression to draw a clear difference between these two use cases in the top-level API, while still maintaining the original contract of the analyse function for convenience and backward compatibility.

The end result is to have three functions exported from the escomplex module:

• analyse
• analyseModule
• analyseProject

The analyse function would then simply delegate to either analyseModule or analyseProject based on the shape of the first argument, passing the options object through.

As mentioned in #30, Espree constitutes a better default parser that makes Esprima compatibility an explicit design goal. Replace Esprima with Espree as the default parser in index.js

There are a number of issues and PRs that have been landed to the master branch, but haven't been released. Update the list of unreleased changes to represent all closed issues for the 2.0.0 milestone.

McCabe's cyclomatic complexity is defined as V(p) = e - n + 2p. For p = 1, it should be calculated as follows: V(p) = π + 1, where π is the number of predicates in the program. It seems like you are missing the predicates made of the && - operator?

I have a file with these lines of code:

const smArr = [5, 3, 2, 35, 2];
const bigArr = [5, 3, 2, 35, 2, 5, 3, 2, 35, 2, 5, 3, 2, 35, 2, 5, 3, 2, 35, 2, 5, 3, 2, 35, 2, 5, 3, 2, 35, 2, 5, 3, 2, 35, 2, 5, 3, 2, 35, 2, 5, 3, 2, 35, 2, 5, 3, 2, 35, 2];

//O(log n)
const sort = arr => {
    if (arr.length < 2) return arr;
  
    let pivot = arr[0];
    let left = [];
    let right = [];
  
    for (let i = 1, total = arr.length; i < total; i++) {
      if (arr[i] < pivot) left.push(arr[i]);
      else right.push(arr[i]);
    };
    return [
      ...sort(left),
      pivot,
      ...sort(right)
    ];
  };

sort(smArr); // 0 Milliseconds
sort(bigArr); // 1 Millisecond

It contains 1 if and 1 if-else inside a for loop. However, cyclomatic returns 1. Is it correct?