tobie / module-grapher Goto Github PK

View Code? Open in Web Editor NEW

11.0 4.0 4.0 146 KB

Node library for resolving and graphing Common JS module dependencies.

License: Other

JavaScript 100.00%

module-grapher's Introduction

This repository is no longer maintained.

module-grapher

module-grapher resolves CommonJS module dependencies through recursive static analysis.

Although itself a node.js program, module-grapher's main target is client-side code.

While it can be used to build dependency graphs of node programs, it is unaware of node's special node_modules directory or NPM's nested package dependencies conventions. In fact, module-grapher is totally unaware of packages at large (it supports search paths, however). Programs relying on external packages will need to install them via a package manager like Kris Zyp's excellent CPM. module-grapher is designed to resolve module dependencies, not package dependencies.

In the future, module-grapher might become package-aware to handle cases where multiple versions of the same package are required, but this is not currently a priority.

module-grapher supports CoffeeScript and can be easily extended to support other languages which compile to JavaScript.

Install

module-grapher is available as an NPM module.

$ npm install module-grapher

Usage

module-grapher accepts an filepath, source code or module identifier as input.

To get dependencies from a module:

require('module-grapher').graph('foo', {
  paths: ['./lib', './vendor'], // defaults to the equivalent of ['.']
  root: 'path/to/package/root/' // defaults to process.cwd()
}, callback);

Other options include:

extensions (defaults to ['.js', '.coffee']): an array of supported extensions.
allowDirModules: Also search for modules in the index file of the directory named after them. So look for module foo/bar not only in foo/bar.js but also in foo/bar/index.js. Defaults to false.
allowMissingModules: don't throw when a module is missing. Just mark it as such. Defaults to false.
allowDynamicModuleIdentifiers: don't throw when the identifier of module isn't a string. Defaults to false.

License

module-grapher's People

Contributors

Stargazers

Watchers

Forkers

jlfwong achien cpojer shaneosullivan

module-grapher's Issues

Dead code removal should occur before static analysis

If I wrap calls to require() in if(DEV) blocks, then the require should get removed before module-grapher tries to determine what modules to include in a build. That way, we can require modules at development-time only, and not impact production builds.

requiring index.js as 'folder' or 'folder/index' shouldn't break relative requires.

Requiring foo/index.js through require('foo') resolves relative module identifiers as if they were required at the level of the foo directory. This is incorrect and should be fixed.

Modules don't build correctly when required from other packages

Something weird about cross-package requires:

pkg1/foo: exports.name = 'pkg1';

pkg1/index: exports.name = require('foo').name;

pkg2/index: require('pkg1/index');

Here pkg2 refuses to build with "Error: Cannot find module: foo". I think what's going on is 'foo' is in the global module namespace for pkg1, but not in the namespace for pkg2. In general, this might be a problem if pkg1 has different paths than pkg2, because modules written for pkg1 compile differently when used in pkg2.

I think it would be nice if pkg1/index builds with the specification in pkg1/package.json, even if it is required inside pkg2/index. However, if that violates CommonJS specifications I think modulr could at least look at pkg1/package.json and display the possible location of 'foo' when compiling pkg2.

Support packages with accurate 'main' values

Node modules have a package.json with a 'main' value that points to the main file in a module. module-grapher does not understand this, and assumes that the filename is a directory.

If the empty string was added as a valid extension, this problem goes away.

diff --git i/lib/src-resolver.js w/lib/src-resolver.js
index 38dbd85..34dd468 100644
--- i/lib/src-resolver.js
+++ w/lib/src-resolver.js
@@ -21,7 +21,7 @@ function SrcResolver(config) {
   function normalizeConfig(input) {
     input = input || {};
     var output = {},
-        exts = input.extensions || ['.js', '.coffee'];
+        exts = input.extensions || ['', '.js', '.coffee'];

     for (var prop in input) {
       output[prop] = input[prop];
@@ -36,7 +36,7 @@ function SrcResolver(config) {

   p.normalizeExtensions = normalizeExtensions;
   function normalizeExtensions(extensions) {
-    return extensions.map(pathHelpers.normalizeExt);
+    return extensions;//.map(pathHelpers.normalizeExt);
   }

Object #<Object> has no method 'relative'

/opt/local/lib/node_modules/modulr/node_modules/module-grapher/lib/src-resolver.js:96
module.relativePath = path.relative(self.config.root, p);
^
TypeError: Object # has no method 'relative'
at /opt/local/lib/node_modules/modulr/node_modules/module-grapher/lib/src-resolver.js:96:38
at /opt/local/lib/node_modules/modulr/node_modules/module-grapher/lib/path-helpers.js:6:5

bash-3.2$ sudo npm install -g path
[email protected] /opt/local/lib/node_modules/path
bash-3.2$ sudo npm install -g module-grapher
[email protected] /opt/local/lib/node_modules/module-grapher

Allow main modules of packages to point to dir modules

Building doesn't currently throw for this, but the scope of the module is incorrect.

should module-grapher support checking lib directory in external packages?

I'm trying to use modulr to require a separate commonJS package outside of my project. Since the package provides a package.json file, I was hoping that module-grapher would automatically look in:

/Users/me/workspace/foo/lib/index.js

when I load foo as

require('foo')

provided I've included /Users/me/workspace in my paths configuration.

Currently it appears to only look in:

/Users/me/workspace/foo/index.js

Is this a bug or are external packages not yet supported?

support require.async

We are using the uncommonjs module specification to write our javascripts.

We use the require.async to loading some js for performance reason.

It would be aweson the module-grapher can analyze the require.async dependencies.