Add jest_cmd option to allow configuring the command

[callumacrae]

I've never written lua or contributed to a plugin before so please treat this accordingly!

This is a good plugin :)

[callumacrae]

i ended up forking as i just wanted to copy to clipboard instead of opening a window inside nvim, but i also improved the matching:

https://github.com/callumacrae/dotfiles/blob/master/vim/config/plugin-config/jest.lua

it supports multi-line test definitions, e.g.:

it(
  'should do something and also has a really long name',
  () => { /* ... *? }
)

it supports function definitions being elsewhere:

it('should test something', testSomething)

function testSomething() {
  // can run :JestSingle from here
}

The second one is quite specific to the project i'm working on and brittle, but feel free to take as much as you'd find useful :)

[kubejm]

My apologies for not looking at this sooner. I'll try to get to this within the next couple of days.

I'll definitely take a look through what you have forked and we could try to pull it into the project.

[kubejm]

I think my inclination is to not store a configuration globally, but rather pass in overriding user configuration via a setup function.

Possibly something like:

require('jest.nvim').setup({
  jest_cmd: 'yarn test --silent'  
})

Here is how treesitter accomplishes this:
https://github.com/nvim-treesitter/nvim-treesitter/blob/master/lua/nvim-treesitter/configs.lua#L377-L400

I can try to look into taking a swing at this in a bit.

[callumacrae]

that's fair - i did it as a config option so that i could override it in project-level config files, but i guess people with that case could just use the option from a project-level config file in the setup call

[kubejm]

I just pushed up a change, so that rather than utilize npx jest it will try to utilize the jest within the relative node_modules directory. Alternatively, you could define your own jest_cmd via the setup function. Additionally, I added silent on by default, but that is also configurable via setup.

If you have a chance, then let me know your thoughts on this. I'll try to capture your other suggestions in separate issues, then tackle them individually.

[callumacrae]

Looks like it mostly solves the case I had!

3da0680

Doesn't this always run setup() again, unless the user manually sets vim.g.loaded_nvim_jest? I'd have thought you wanted to set that in the setup() function, not there

[kubejm]

Doesn't this always run setup() again, unless the user manually sets vim.g.loaded_nvim_jest? I'd have thought you wanted to set that in the setup() function, not there

When plugin/nvim-jest.lua runs for the first time vim.g.loaded_nvim_jest will be falsey, because it is undefined. Subsequently, it sets vim.g.loaded_nvim_jest to true indicating that it has initialized and require('nvim-jest').setup() is invoked.

If plugin/nvim-jest.lua again, then vim.g.loaded_nvim_jest will be true. The file will immediately short-circuit and return. So, require('nvim-jest').setup() would not be invoked again.

The reason I thought to put require('nvim-jest').setup() within plugin/nvim-jest.lua is so users do not need to invoke require('nvim-jest').setup() within their own vim configuration to initialize the plugin. However, this is leading to some funny code within the setup() function, because I believe plugin managers would likely invoke the user defined setup() before plugin/nvim-jest.lua and I want the user defined configuration to take precedence. I'm going to think through another strategy to simplify this.