moog-require - npm Package Compare versions

Comparing version 1.3.0 to 1.3.1

index.js

@@ -162,2 +162,13 @@ var async = require('async');
     }
+    // Even if the package exists in node_modules it might just be a
+    // sub-dependency due to npm/yarn flattening, which means we could be
+    // confused by an unrelated npm module with the same name as an Apostrophe
+    // module unless we verify it is a real project-level dependency
+    if (!self.validPackages) {
+      const info = JSON.parse(fs.readFileSync(`${path.dirname(self.root.filename)}/package.json`, 'utf8'));
+      self.validPackages = new Set([ ...Object.keys(info.dependencies || {}), ...Object.keys(info.devDependencies || {}) ]);
+    }
+    if (!self.validPackages.has(type)) {
+      return null;
+    }
     try {
@@ -164,0 +175,0 @@ return npmResolve.sync(type, { basedir: path.dirname(parentPath) });

package.json

@@ -41,3 +41,3 @@ {
   },
-  "version": "1.3.0"
+  "version": "1.3.1"
 }

README.md

@@ -353,2 +353,4 @@ [![Build Status](https://travis-ci.org/punkave/moog-require.svg?branch=master)](https://travis-ci.org/punkave/moog-require)
 
+1.3.1: `moog-require` loads modules from npm if they exist there and are configured by name in the application. This was always intended only as a way to load direct, intentional dependencies of your project. However, since npm "flattens" the dependency tree, dependencies of dependencies that happen to have the same name as a project-level module could be loaded by default, crashing the site or causing unexpected behavior. So beginning with this release, `moog-require` scans `package.json` to verify an npm module is actually a dependency of the project itself before attempting to load it.
+
 1.3.0: achieved an approximately 100x performance improvement when `nestedModuleSubdirs` is in use by fetching
@@ -355,0 +357,0 @@ a list of index.js files on the first `define` call and then searching that prefetched list each

test/test.js

@@ -203,20 +203,2 @@ var assert = require('assert');
 
-    it('should create a subclass when the parent is an npm dependency of the subclass', function(done) {
-      synth = require('../index.js')({
-        localModules: __dirname + '/project_modules',
-        root: module
-      });
-
-      synth.define({
-        'testModuleFour': {}
-      });
-
-      synth.create('testModuleFour', {}, function(err, testModuleFour) {
-        assert(!err);
-        assert(testModuleFour);
-        assert(testModuleFour._options.age === 70);
-        return done();
-      });
-    });
-
   });
@@ -810,3 +792,11 @@
   });
-
+  it('should load a project level module properly when a transitive dependency not in package.json nevertheless has the same name and appears in node_modules', function() {
+    var synth = require('../index.js')({
+      localModules: __dirname + '/project_modules',
+      root: module
+    });
+    synth.define('sameNameAsTransitiveDependency');
+    var instance = synth.create('sameNameAsTransitiveDependency', {});
+    assert(instance.confirm === 'loaded');
+  });
 });

New alerts

New author

Supply chain risk

A new npm collaborator published a version of the package for the first time. New collaborators are usually benign additions to a project, but do indicate a change to the security surface area of a package.

Found 1 instance in 1 package

Improved metrics

Total package byte prevSize

54949

increased by3.7%

Number of package files

36

increased by9.09%

Lines of code

1035

increased by1.07%

Number of lines in readme file

379

increased by0.53%

Worsened metrics

Number of medium supply chain risk alerts

1

increased byInfinity%

No dependency changes