[vim/vim] runtime:compiler:feat: unify node-based makeprgs (PR #18798)

Enno

unread,

Nov 22, 2025, 2:13:05 AMNov 22

to vim/vim, Subscribed

Follow-up to closed #18755
Now defaults to npx as suggested by @romainl and @dkearns ; let the user optionally change it by b/g:node_makeprg and documented where documentation existed; @dkearns 's b/g:tsc_makeprg kept for backwards compatibility; would that be acceptable, @djmoch ?

You can view, comment on, or merge this pull request online at:

https://github.com/vim/vim/pull/18798

Commit Summary

91428c1 runtime:compiler:feat: unify node-based makeprgs

File Changes

(15 files)

Patch Links:

—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.

Enno

unread,

Nov 22, 2025, 2:29:56 AMNov 22

to vim/vim, Push

@Konfekt pushed 1 commit.

efe6e30 feat: add per-compiler makeprg checks and prefer them over node_makeprg

—
View it on GitHub or unsubscribe.
You are receiving this because you are subscribed to this thread.

dkearns

unread,

Nov 22, 2025, 3:13:11 AMNov 22

to vim/vim, Subscribed

dkearns left a comment (vim/vim#18798)

I don't have a good short term solution but these variables are really starting to make a mess of the global namespace. I know you've tried to broach this topic before.

I wonder if sticking this under g:javascript_node_* would be better. Except for all the exceptions, primarily variables used internally by Vim, g:node_ would indicate a config variable for the node filetype. We don't have one yet but it will probably be added soon after we commit to this name and have nothing to do with JavaScript Node.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

Enno

unread,

Nov 22, 2025, 3:34:29 AMNov 22

to vim/vim, Push

@Konfekt pushed 1 commit.

14013f1 refactor: shorten makeprg setup with ternary in compilers

—
View it on GitHub or unsubscribe.

You are receiving this because you are subscribed to this thread.

Enno

unread,

Nov 22, 2025, 3:37:36 AMNov 22

to vim/vim, Push

@Konfekt pushed 1 commit.

2f9c57c use javascript_node_makeprg instead of node_makeprg as suggested by @dkearns

—
View it on GitHub or unsubscribe.

You are receiving this because you are subscribed to this thread.

Enno

unread,

Nov 22, 2025, 7:14:39 AMNov 22

to vim/vim, Subscribed

Konfekt left a comment (vim/vim#18798)

In

" syntax/javascript.vim (line 77)
if exists("javaScript_fold")

there is rather javaScript, but let's prefer javascript as it is a single word rather than a composed one, even though this increases the namespace again a bit

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

Enno

unread,

Nov 22, 2025, 7:16:38 AMNov 22

to vim/vim, Push

@Konfekt pushed 1 commit.

6a809ad fix: mixed indent

—
View it on GitHub or unsubscribe.

You are receiving this because you are subscribed to this thread.

Enno

unread,

Nov 22, 2025, 7:27:45 AMNov 22

to vim/vim, Push

@Konfekt pushed 1 commit.

4f882b7 fix: mixed indent

—
View it on GitHub or unsubscribe.

You are receiving this because you are subscribed to this thread.

Daniel Moch

unread,

Nov 22, 2025, 7:30:03 AMNov 22

to vim/vim, Subscribed

djmoch left a comment (vim/vim#18798)

would that be acceptable, @djmoch ?

If you're going to make changes, please remove me as the maintainer. I am not really using these anymore and don't want to stand in the way of anyone else making improvements. Perhaps you should adopt them yourself, @Konfekt.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

Enno

unread,

Nov 22, 2025, 7:41:58 AMNov 22

to vim/vim, Push

@Konfekt pushed 1 commit.

de4aa62 remove @djmoch as maintainer

—
View it on GitHub or unsubscribe.

You are receiving this because you are subscribed to this thread.

Enno

unread,

Nov 22, 2025, 10:17:50 AMNov 22

to vim/vim, Subscribed

Konfekt left a comment (vim/vim#18798)

@djmoch When you say changes, do you mean any change to the file or in substance? Replacing

get(g:, 'csslint_makeprg', '')

to

get(g:, 'csslint_makeprg', 'csslint')

will fully restore the previous behavior of, for example, csslint.
Same can be done for the other file.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

Daniel Moch

unread,

Nov 22, 2025, 10:19:50 AMNov 22

to vim/vim, Subscribed

djmoch left a comment (vim/vim#18798)

do you mean any change to the file or in substance? Replacing

Any change. I have no plans to maintain these in the future.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

Christian Brabandt

unread,

Nov 23, 2025, 1:34:54 PMNov 23

to vim/vim, Subscribed

@chrisbra commented on this pull request.

Thanks, but I am not so happy with introducing a whole batch of new option variables and in addition use those javascript_node_ variables as fallback. Can't we stick to one single way to do it? This is quite hard to understand and maintain as it is now.

Also can you please revert those whitespace changes?

In runtime/compiler/biome.vim:

>  if exists("current_compiler") | finish | endif
 let current_compiler = "biome"
 
 let s:cpo_save = &cpo
 set cpo&vim
 
-exe 'CompilerSet makeprg=' .. escape('biome check --linter-enabled=true --formatter-enabled=false --assist-enabled=false --reporter=github '
-      \ .. get(b:, 'biome_makeprg_params', get(g:, 'biome_makeprg_params', '')), ' \|"')
+" CompilerSet makeprg=biome
+" CompilerSet makeprg=npx\ biome
+exe 'CompilerSet makeprg=' .. escape(
+                      \ (!empty(get(b:, 'biome_makeprg', get(g:, 'biome_makeprg', ''))) ?
+                      \   get(b:, 'biome_makeprg', get(g:, 'biome_makeprg', '')) :

Biome is quite new, let's rather keep it simple and jut use the javascript_node_makeprg instead and get rid of the whole biome_makeprg option instead. This simplifies this whole thing here.

In runtime/compiler/csslint.vim:

>  
 if exists("current_compiler")
   finish
 endif
 let current_compiler = "csslint"
 
-CompilerSet makeprg=csslint\ --format=compact
+" CompilerSet makeprg=csslint
+" CompilerSet makeprg=npx\ csslint
+exe 'CompilerSet makeprg=' .. escape(
+                      \ (!empty(get(b:, 'csslint_makeprg', get(g:, 'csslint_makeprg', ''))) ?
+                      \   get(b:, 'csslint_makeprg', get(g:, 'csslint_makeprg', '')) :

same here, let's not introduce another block of settings but stick to javascript_node_makeprg

In runtime/compiler/eslint.vim:

>  
 if exists("current_compiler")
   finish
 endif
 let current_compiler = "eslint"
 
-CompilerSet makeprg=npx\ eslint\ --format\ stylish
+" CompilerSet makeprg=eslint
+" CompilerSet makeprg=npx\ eslint
+exe 'CompilerSet makeprg=' .. escape(
+                        \ (!empty(get(b:, 'eslint_makeprg', get(g:, 'eslint_makeprg', ''))) ?
+                        \   get(b:, 'eslint_makeprg', get(g:, 'eslint_makeprg', '')) :

similar here please

In runtime/compiler/jest.vim:

>  CompilerSet errorformat=%-A\ \ ●\ Console,
-		       \%E\ \ ●\ %m,
-		       \%Z\ %\\{4}%.%#Error:\ %f:\ %m\ (%l:%c):%\\=,
-		       \%Z\ %\\{6}at\ %\\S%#\ (%f:%l:%c),
-		       \%Z\ %\\{6}at\ %\\S%#\ %f:%l:%c,
-		       \%+C\ %\\{4}%\\w%.%#,
-		       \%+C\ %\\{4}%[-+]%.%#,
-		       \%-C%.%#,
-		       \%-G%.%#
+                       \%E\ \ ●\ %m,

Can you revert those whitespace changes?

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.

Enno

unread,

Nov 23, 2025, 3:19:25 PMNov 23

to vim/vim, Push

@Konfekt pushed 1 commit.

a22df55 use tabs for erroformat as kindly pointed out by @chrisbra

—
View it on GitHub or unsubscribe.

You are receiving this because you are subscribed to this thread.

Enno

unread,

Nov 23, 2025, 3:24:22 PMNov 23

to vim/vim, Subscribed

Konfekt left a comment (vim/vim#18798)

Thanks, but I am not so happy with introducing a whole batch of new option variables and in addition use those javascript_node_ variables as fallback. Can't we stick to one single way to do it? This is quite hard to understand and maintain as it is now.

See #18798 (comment) regarding variable pollution; one could guard them behind their main file types as well, though, say, biome treats many.

Having an executable in PATH to apply formatting independent of the repo one is in still has use cases, say scratch files, docs, ...

From what I saw, npx in HOME will install node_modules in HOME, rather than globally npm install -g, so I don't know how to offer that other than giving the user the option to do so.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

Enno

unread,

Nov 24, 2025, 6:09:40 AMNov 24

to vim/vim, Subscribed

Konfekt left a comment (vim/vim#18798)

I don't have a good short term solution but these variables are really starting to make a mess of the global namespace

Most natural would be simply inverting the order, b:makeprg_(params_)tsc, so that suffixed makeprg vars are used for compiler settings. Adding backward compatible mappings (if ever deemed worth it) will not be too much effort.

Of course, one could also think even larger, and agree on a g:vimrc prefix or similar, so that g:vimrc_makeprg indeed should be rather unique

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

dkearns

unread,

Nov 26, 2025, 5:00:26 AMNov 26

to vim/vim, Subscribed

dkearns left a comment (vim/vim#18798)

I strongly dislike the use of config variables for anything that can be trivially managed with the "after-directory" mechanism. I would be happy enough just to use npx for any of these NPM packaged tools and call it a day. A config variable to globally switch this approach with normal PATH based lookup might be convenient for some users but I wouldn't have added it myself.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

Christian Brabandt

unread,

Nov 26, 2025, 3:29:48 PMNov 26

to vim/vim, Subscribed

chrisbra left a comment (vim/vim#18798)

I would be happy enough just to use npx for any of these NPM packaged tools and call it a day

I tend to agree. Thanks

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

Enno

unread,

Nov 28, 2025, 12:29:48 PMNov 28

to vim/vim, Subscribed

Konfekt left a comment (vim/vim#18798)

can be trivially managed with the "after-directory"

I simply was not aware of it I thought one had to basically copy-paste the definition from VIMRUNTIME to HOME and adapt it. Instead, setting &makeprg in $HOME/.vim/after/compiler/xyz.vim will only override &makeprg (and leave &errorformat as in VIMRUNTIME/compiler/xyz.vim?

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

Enno

unread,

Nov 29, 2025, 4:25:59 AMNov 29

to vim/vim, Subscribed

Konfekt left a comment (vim/vim#18798)

I thought a bit more about it and now disagree:

Even though, say, only &makeprg can be overridden in an after/compiler/ file, it is tied to &errorformat, see, say, latest adaptions to eslint.vim.

So overriding only &makeprg leads to trouble down the road when it goes out of sync with$VIMRUNTIME's &errorformat, tied to a different &makeprg.
To avoid that the user would have to maintain an adapted full copy of the compiler/xyz.vim file which is asking too much from the user; for example, many syntax and ftplugin files allow the user to set certain values, such as for folding, to spare them from having to replicate and tweak them.

So yes, I think from a user perspective, the safer and easier option is just to change the concerned property, say name of the executable, in a line in the vimrc.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

Enno

unread,

Nov 29, 2025, 4:28:14 AMNov 29

to vim/vim, Subscribed

Konfekt left a comment (vim/vim#18798)

What one can do, say by a naming scheme, to contain the names of the variables to set these values, at the moment freely left to the maintainer's choice, be it ftplugin, syntax, compiler, ... , is an issue apart (elsewhere, @dkearns mentioned it but I cannot find it right now).

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

Enno

unread,

Dec 18, 2025, 12:54:33 AM (23 hours ago) Dec 18

to vim/vim, Subscribed

Konfekt left a comment (vim/vim#18798)

I strongly dislike the use of config variables for anything that can be trivially managed with the "after-directory"

A point of contention could be what counts as trivial here; what's trivial for experienced maintainers of Vim runtime files might be non-obvious for a user working on the Vim documentation level; less experienced users might prefer to set customizing options in the Vim help, instead of forking runtime files into the user's directory and editing suitably (which, as they might go out of sync, could also be a preferred option for those having that expertise, but that was already mentioned above).

Another advantage to using a variable to tweak the makeprg options is that this is more easily done at a (node, python, ..) project local vimrc , with no need to add in it additional (after) runtime paths