Update resolver docs

The `packageFilter` option to `defaultResolver` appears to have gone away as part of #15619. The versioned 30.0 docs were correctly updated, but the "Next" docs were not.

Shorten the URL comment to make it less likely to induce scrolling.

I also added another example of a resolver that I've found useful in my own project. Feedback/corrections welcome.

Author: joshkel

docs/Configuration.md

@@ -1522,25 +1522,38 @@ const config: Config = {
 export default config;
 ```
 
-By combining `defaultResolver` and `packageFilter` we can implement a `package.json` "pre-processor" that allows us to change how the default resolver will resolve modules. For example, imagine we want to use the field `"module"` if it is present, otherwise fallback to `"main"`:
+Jest's `jest-resolve` relies on `unrs-resolver`. We can pass additional options, for example modifying `mainFields` for resolution. For example, for React Native projects, you might want to use this config:
 
 ```js
 module.exports = (path, options) => {
   // Call the defaultResolver, so we leverage its cache, error handling, etc.
   return options.defaultResolver(path, {
     ...options,
-    // Use packageFilter to process parsed `package.json` before the resolution (see https://www.npmjs.com/package/resolve#resolveid-opts-cb)
-    packageFilter: pkg => {
-      return {
-        ...pkg,
-        // Alter the value of `main` before resolving the package
-        main: pkg.module || pkg.main,
-      };
-    },
+    // `unrs-resolver` option: https://github.com/unrs/unrs-resolver#main-field
+    mainFields: ['react-native', 'main'],
   });
 };
 ```
 
+You can also use `defaultResolver` to implement a "pre-processor" that allows us to change how the default resolver will resolve modules. For example, suppose a TypeScript project needs to reference `.js` files at runtime but runs Jest on the `.ts` files.
+
+```js
+module.exports = (path, options) => {
+  // Dynamic imports within our codebase that reference .js need to reference
+  // .ts during tests.
+  if (
+    !options.basedir.includes('node_modules') &&
+    path.endsWith('.js') &&
+    (path.startsWith('../') || path.startsWith('./'))
+  ) {
+    path = path.replace(/\.js$/, '.ts');
+  }
+
+  // Call the defaultResolver, so we leverage its cache, error handling, etc.
+  return options.defaultResolver(path, options);
+};
+```
+
 ### `restoreMocks` \[boolean]
 
 Default: `false`

website/versioned_docs/version-30.0/Configuration.md

@@ -1536,12 +1536,31 @@ module.exports = (path, options) => {
   // Call the defaultResolver, so we leverage its cache, error handling, etc.
   return options.defaultResolver(path, {
     ...options,
-    // See this `unrs-resolver` option: from https://github.com/unrs/unrs-resolver?tab=readme-ov-file#main-field
+    // `unrs-resolver` option: https://github.com/unrs/unrs-resolver#main-field
     mainFields: ['react-native', 'main'],
   });
 };
 ```
 
+You can also use `defaultResolver` to implement a "pre-processor" that allows us to change how the default resolver will resolve modules. For example, suppose a TypeScript project needs to reference `.js` files at runtime but runs Jest on the `.ts` files.
+
+```js
+module.exports = (path, options) => {
+  // Dynamic imports within our codebase that reference .js need to reference
+  // .ts during tests.
+  if (
+    !options.basedir.includes('node_modules') &&
+    path.endsWith('.js') &&
+    (path.startsWith('../') || path.startsWith('./'))
+  ) {
+    path = path.replace(/\.js$/, '.ts');
+  }
+
+  // Call the defaultResolver, so we leverage its cache, error handling, etc.
+  return options.defaultResolver(path, options);
+};
+```
+
 ### `restoreMocks` \[boolean]
 
 Default: `false`