-
Notifications
You must be signed in to change notification settings - Fork 2.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
shrink util
implementation by using upstream functions, avoid util
in configs
#2079
Comments
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
We don't necessarily need to remove |
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
Plan
we should keep the util stuff around to avoid breaking downstream. meanwhile, in this repo:
once we have isolated most of |
Since we don't actually test/run any of the lua configs in CI to my knowledge, the best we can hope for is to make a string search of changed lines on PRs and complain if the deprecated function is used. |
The "Proposal" in the main description of this issue is updated and correct. To be clear:
For example, nvim-lspconfig/lua/lspconfig/util.lua Line 248 in 39f31e1
|
utils
with upstream functionsutil
implementation by using upstream functions, avoid util
in configs
Statusrelated work: |
I'm not really a fan of the suggested deprecation strategy. It creates extra CI work and makes the process harder because we now need to have bookkeeping of which util functions we use ourselves and which util functions are there for public use. What was so wrong about the previous deprecation strategy that we need to invent a new one on the spot? |
There was no previous deprecation strategy for nvim-lspconfig. The goal is to shrink nvim-lspconfig in order to make progress towards upstreaming it, while minimizing damage to user trust. Which part of the above plan, specifically, do you want to change, and how, specifically? (Other than the CI work, which is merely a way to reduce the code review burden of nvim-lspconfig, and something that will materialize depending on the whims of the people maintaining nvim-lspconfig: #3462 .) |
Ok I see what you mean from the discussion in #3460 |
#3460 is a good example of why removing As we hollow-out the guts of |
The proposed strategy is alright I guess, it's just more safe/careful than my personal preference. And I like having one deprecation strategy over all our repos if possible to reduce the mental overhead of keeping track of different strategies. But I can work with the strategy you outlined, it's not a dealbreaker and we can make progress like you said. |
Use `vim.uv.fs_stat` instead. Work on neovim#2079.
Use `vim.uv.fs_stat` instead. Work on neovim#2079.
Use `vim.uv.fs_stat` instead. Work on neovim#2079.
Functions to deprecate
These functions can be replaced with relevant functions
vim.fs
:path.
dirname
ci: check for deprecated util functions #3462sanitize
refactor: remove internal implementation ofutil.path.sanitize
#3464exists
refactor: deprecateutil.path.exists
#3471is_dir
refactor: deprecate util.path.is_dir #3475is_file
refactor: deprecate util.path.is_file #3474search_ancestors
root_pattern
find_git_ancestors
refactor: deprecate util.find_git_ancestor #3507find_mercurial_ancestors
refactor: deprecate util.find_mercurial_ancestor #3476find_node_modules_ancestors
refactor: deprecate util.find_node_modules_ancestor #3477find_package_json_ancestors
refactor: deprecate util.find_package_json_ancestor #3502These functions can be made private in the next releases seeing as
user_commands
part has already been signaled for eventual deprecation:parse_user_command_options
create_module_commands
Proposal
nvim 0.8
+ stabilization period.vim.fs
.configs/[server].lua
wherever relevantutil
functions. ci: check for deprecated util functions #3462The text was updated successfully, but these errors were encountered: