Fix subprocess module loading issue for build_position

[ThomasCode92]

Problem

When build_position is passed as a string 'require("neotest-jest").build_position' to lib.treesitter.parse_positions(), it fails to load in subprocess context. This causes several issues:

• Test discovery fails with module 'neotest-jest' not found errors
• Users see "No tests found" even when tests exist

This issue was reported in #165.

Root Cause

Neotest uses subprocesses for parsing test positions for performance. When a string is passed as build_position, neotest tries to loadstring() and execute it in the subprocess. However, in the subprocess context, require("neotest-jest") fails because the module isn't properly loaded in that isolated environment.

From the neotest source code:

if type(opts.build_position) == "string" then
  local loaded, err = loadstring("return " .. opts.build_position)
  assert(loaded, ("Couldn't parse \`build_position\` option: %s"):format(err))
  opts.build_position = loaded()
end

The subprocess tries to execute require("neotest-jest").build_position but the module context doesn't exist there.

Solution

This PR changes line 286 from:

build_position = 'require("neotest-jest").build_position',

To:

build_position = adapter.build_position,

By passing the function directly instead of a string reference, neotest automatically disables subprocess mode for this adapter (as documented in neotest's code):

if type(opts.build_position) == "function" or type(opts.position_id) == "function" then
  logger.warn(
    "Using \`build_position\` or \`position_id\` functions with subprocess parsing is not supported, switch to using strings for remote calls"
  )
  return neotest.lib.treesitter._parse_positions(file_path, query, opts)
end

This fallback to non-subprocess parsing avoids all module loading issues while maintaining functionality.

Trade-offs

• Pro: Fixes test discovery for all users experiencing the issue
• Pro: Simple one-line change
• Con: Disables subprocess mode for parsing, which may have a minor performance impact on very large codebases
• Note: The performance impact should be negligible for most projects, and correctness is more important than the minor optimization

Testing

Tested with:

• Jest projects with standard test file patterns (.test.ts, .spec.js)
• Projects with custom test directory structures
• Verified that tests are now discovered and run correctly
• Confirmed test statuses (passed/failed) are reported accurately

Fixes #165

[MisanthropicBit]

@ThomasCode92 Thanks for submitting a PR 🙂

Thanks for providing all that information.

Neotest should actually handle making the adapters available for the remote call but somewhat recent changes to that logic on the neotest repo made a bunch of adapters fail. This was also reported by OP #165 (comment) and there is a tracking issue here: nvim-neotest/neotest#531 (you have also commented on that issue I see).

Can you confirm that you are not actually hitting that case by downgrading to the commit before ce17830? I would very much like to keep subprocess parsing, especially for big repos that I also work on sometimes, since build_position is now necessary to support certain features.

I tried upgrading to follow the main branch again and it seems some of the patches have worked for me at least.

[ThomasCode92]

@MisanthropicBit I didn’t try downgrading to the pre-ce17830 commit. Instead, I upgraded everything to the latest versions on the main/master branches. These are the commits I’m currently on:

"neotest": { "branch": "master", "commit": "deadfb1af5ce458742671ad3a013acb9a6b41178" },
"neotest-golang": { "branch": "main", "commit": "37e400cfe9d193e508b1a512e96cbef83b08deb6" },
"neotest-jest": { "branch": "main", "commit": "a36df9109c75bd1ae46b7bad274615dbbe6e4dcd" },
"neotest-python": { "branch": "master", "commit": "b0d3a861bd85689d8ed73f0590c47963a7eb1bf9" },
"neotest-vitest": { "branch": "main", "commit": "8bc784d319889a39c7ed8045ff7b0f12770c7b54" },

With this setup, I can confirm that Golang and Vitest tests are working as expected. Jest tests, however, are still failing for me.

Am I possibly still hitting the adapter availability issue, or missing another required change? Also, when you mention following the main branch, do you mean neotest itself, neotest-jest, or both?

[MisanthropicBit]

I didn’t try downgrading to the pre-ce17830 commit.

Please do and confirm that it is not the issue. I followed the issues over on neotest and it seemed like the fixes worked for some users/adapters but not others. This is not going to be a straight-forward change so I want to be certain this is ruled out.

If the issue still persists on the pre-ce17830 commit, a minimal repro would be most welcome as well.

Thanks for posting the shas. Looks like you are running against the most recent commit on neotest and neotest-jest.

With this setup, I can confirm that Golang and Vitest tests are working as expected. Jest tests, however, are still failing for me.

The issue still isn't resolved on neotest and the fixes have only worked for some users/adapters so far. I'm not 100% sure why.

Am I possibly still hitting the adapter availability issue, or missing another required change? Also, when you mention following the main branch, do you mean neotest itself, neotest-jest, or both?

I'm assuming you are running neovim 0.9.0+, you are already running neotest 0.4.0+, and the only other requirement would be to install the appropriate tree-sitter parsers. I meant neotest's main branch which you are already following.