mattn
Project-local config file
efm-langserver could be a pretty handy tool for unifying project linting and formatting across developer machines and editors/IDEs. What prevents this from working easily is an option for project-local configuration files, where the project conventions can easily be enforced. Therefore, adding something like ${workspace_root}/.efm-config.yaml to the configuration cascade would be pretty handy. Otherwise, every developer has to explicitly instruct its IDE to launch with the project-local configuration file, which is more work and can be easily missed.
If the repository you git cloned has an .efm-config.yaml that you didn't notice, and it contains a configuration that deletes your important files, what can we do about it?
That situation would be the same with vim's .exrc or many other configuration files for IDEs. I can also include arbitrary commands from a maven pom.xml or a tox configuration in Python and so on. So you should probably never trust a foreign project configuration before reviewing it.
Maybe adding some configuration parameter (set via LSP capabilities or in the global config file) defaulting to false that adds support for local project configs could be an option that prevents unknowing users from such a situation.
FYI, vim does not load .exrc if you don't set set exrc. VSCode show confirmation dialog to trust the local settings. And vim-lsp-settings does not load local-configuration file.
Yes, but if there was an option to "trust" local EFM configs, wouldn't that be the same thing then?
embear/vim-localvimrc provides a very similar user experience to the recently-introduced VS Code trust flow. I recommend checking it out. In my project, I create an .lvimrc file, as the plugin instructs, with the following content:
lua <<EOF
local dyn = require('cyberdyne.lsp')
dyn.set_formatter_order('efm')
dyn.setup_server('efm', {
cmd = { 'efm-langserver', '-c', './.efmrc.yaml' },
filetypes = { 'javascript', 'javascriptreact', 'typescript', 'typescriptreact' },
})
EOF
You can ignore the cyberdyne references. It's my own private package that contains LSP config helpers.
Any time I edit this file, I get prompted to trust it again when vim starts up.
I think that's an overall better approach versus asking each integration like efm-langserver to include a trust flow.
VSCode show confirmation dialog to trust the local settings.
This is a common approach.
For example, direnv is a tool that auto-sources .envrc/.env files as you cd into directories.
If you download a repo that contains a .envrc file and you cd into it, direnv will show an error:
direnv: error /path/to/.envrc is blocked. Run `direnv allow` to approve its content
After trusting it, if it has been modified by any process, it will error again and will not auto-source the file until the user reviews and re-allows it.
