Potential NTARH incompatibility with next/jest.js

[Xunnamius]

As discussed in #983.

Seems next/jest.js calls some sort of internal environmental setup function for http/https "agents" that ends up changing the nature of the Request object; specifically: spreading the Request object functions differently. This occurs when calling nextJest in const createJestConfig = nextJest({ dir: './' }) where nextJest is defined as import nextJest from 'next/jest.js'. When the dir option is omitted, the discussed error does not occur.

Drilling into what the function returned by calling createJestConfig in const jestConfig = await createJestConfig(config)() is actually doing, we get the following stack:

const jestConfig = await createJestConfig(config)()

const createJestConfig = nextJest({
  // Provide the path to your Next.js app to load next.config.js and .env files in your test environment
  dir: './'
});

function nextJest(options = {}) {
    // createJestConfig
    return (customJestConfig)=>{
        // Function that is provided as the module.exports of jest.config.js
        // Will be called and awaited by Jest
        return async ()=>{
...
            if (options.dir) {
                const resolvedDir = (0, _path.resolve)(options.dir);
                const packageConfig = loadClosestPackageJson(resolvedDir);
                isEsmProject = packageConfig.type === "module";
                nextConfig = await getConfig(resolvedDir);
...

async function getConfig(dir) {
    const conf = await (0, _config.default)(_constants.PHASE_TEST, dir);
    return conf;
}

// Is the "default" export of "config"
async function loadConfig(phase, dir, { customConfig, rawConfig, silent = true, onLoadUserConfig } = {}) {
...
assignDefaults(dir, ...)
..

function assignDefaults(dir, userConfig, silent) {
...
(0, _setuphttpagentenv.setHttpClientAndAgentOptions)(result || _configshared.defaultConfig);
...

This is the function that, once executed, somehow subtly changes what @whatwg-node/server's createServerAdapter() returns:

function setHttpClientAndAgentOptions(config) {
    if (globalThis.__NEXT_HTTP_AGENT) {
        // We only need to assign once because we want
        // to reuse the same agent for all requests.
        return;
    }
    if (!config) {
        throw new Error("Expected config.httpAgentOptions to be an object");
    }
    globalThis.__NEXT_HTTP_AGENT_OPTIONS = config.httpAgentOptions;
    globalThis.__NEXT_HTTP_AGENT = new _http.Agent(config.httpAgentOptions);
    globalThis.__NEXT_HTTPS_AGENT = new _https.Agent(config.httpAgentOptions);
}

Rather than investigate this further, it seems whatever is going on is not really an NTARH issue. The solution here is to just explicitly declare/reference each valid property in the Request constructor's options parameter instead of trying to spread the Request instance to grab its properties.

[Xunnamius]

🎉 This issue has been resolved in version 4.0.5 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀