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.

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

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.

@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.

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

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

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.

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

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.

Sorry, I don't follow. Why can't you use consistently npx in that case then?

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.

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

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?

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.

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).

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