jest-pnp-resolver - npm Package Compare versions

Comparing version 1.2.1 to 1.2.2

index.js

@@ -1,41 +0,49 @@
-
-let pnp;
-
+let globalPnpApi;
 try {
-  pnp = require(`pnpapi`);
-} catch (error) {
-  // not in PnP; not a problem
+    globalPnpApi = require(`pnpapi`);
+} catch {
+    // Just ignore if we don't have a global PnP instance - perhaps
+    // we'll eventually find one at runtime due to multi-tree
 }
 
-let defaultResolver;
+const createRequire = require(`./createRequire`);
+const getDefaultResolver = require(`./getDefaultResolver`);
 
-function requireDefaultResolver() {
-  if (!defaultResolver) {
-    try {
-      defaultResolver = require(`jest-resolve/build/defaultResolver`).default;
-    } catch (error) {
-      defaultResolver = require(`jest-resolve/build/default_resolver`).default;
-    }
-  }
-
-  return defaultResolver;
-}
-
 module.exports = (request, options) => {
   const {basedir, defaultResolver, extensions} = options;
 
-  if (pnp) {
-    const resolution = pnp.resolveRequest(request, `${basedir}/`, {extensions});
+  if (process.versions.pnp) {
+    let pnpApi = globalPnpApi;
 
-    // When the request is a native module, Jest expects to get the string back unmodified, but pnp returns null instead.
-    if (resolution === null)
-      return request;
+    // While technically it would be more correct to run this code
+    // everytime (since they file being run *may* belong to a
+    // different dependency tree than the one owning Jest), in
+    // practice this doesn't happen anywhere else than on the Jest
+    // repository itself (in the test env). So in order to preserve
+    // the performances, we can afford a slight incoherence here.
+    if (!pnpApi) {
+      try {
+        const baseReq = createRequire(`${basedir}/internal.js`);
+        pnpApi = baseReq(`pnpapi`);
+      } catch {
+        // The file isn't part of a PnP dependency tree, so we can
+        // just use the default Jest resolver.
+      }
+    }
 
-    return resolution;
-  } else {
-    if (!defaultResolver)
-      defaultResolver = requireDefaultResolver();
+    if (pnpApi) {
+      const resolution = pnpApi.resolveRequest(request, `${basedir}/`, {extensions});
 
-    return defaultResolver(request, options);
+      // When the request is a native module, Jest expects to get the string back unmodified, but pnp returns null instead.
+      if (resolution === null)
+        return request;
+
+      return resolution;
+    }
   }
+
+  if (!defaultResolver)
+    defaultResolver = getDefaultResolver();
+
+  return defaultResolver(request, {...options, allowPnp: false});
 };

package.json

 {
     "name": "jest-pnp-resolver",
-    "version": "1.2.1",
+    "version": "1.2.2",
     "description": "plug'n'play resolver for Webpack",
@@ -5,0 +5,0 @@ "license": "MIT",

README.md

@@ -16,2 +16,4 @@ # <img src="https://github.com/facebook/jest/blob/master/website/static/img/jest.png" height="40" align="right" /> [Plug'n'Play](https://github.com/yarnpkg/rfcs/pull/101) resolver for Jest
 
+As of `jest@^24.4.0` you don't need to manually add this package anymore. The default resolver will already use PnP.
+
 Simply add the resolver to your configuration. For example, a minimal `jest.config.js` would be as such:
@@ -18,0 +20,0 @@

New alerts

Dynamic require

Supply chain risk

Dynamic require can indicate the package is performing dangerous or unsafe dynamic code execution.

Found 1 instance in 1 package

Improved metrics

Total package byte prevSize

5705

increased by45.28%

Number of package files

6

increased by50%

Lines of code

81

increased by102.5%

Number of lines in readme file

35

increased by6.06%

Worsened metrics

Number of low supply chain risk alerts

6

increased by100%

No dependency changes