-
Notifications
You must be signed in to change notification settings - Fork 463
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
feat(plugins): migrate from null-ls
to none-ls
#1088
Conversation
IMO we can switch to `none-ls` before we decide on the best alternative to `null-ls` b/c it's a drop-in replacement for `null-ls`, and we can continue to receive future bug fixes as well.
Can we consider other alternatives like |
my fork repository configuration can be used as a reference,please forgive me if the code is written badly |
I tend to |
As @Mythos-404 stated:
Could u show us some profile numbers to let we know that's the trade-off? Tho there might be some attractive side of Continuity of the user experiences is also a big part when planing migrations, users with less experiences will pop up with A LOT OF issues. However, if it worth the pain, i think we'll all embrace the change! |
Use Migrating |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we can merge it first.
IMO we can switch to `none-ls` before we decide on the best alternative to `null-ls` b/c it's a drop-in replacement for `null-ls`, and we can continue to receive future bug fixes as well.
IMO we can switch to `none-ls` before we decide on the best alternative to `null-ls` b/c it's a drop-in replacement for `null-ls`, and we can continue to receive future bug fixes as well.
IMO we can switch to
none-ls
before we decide on the best alternative tonull-ls
b/c it's a drop-in replacement fornull-ls
, and we can continue to receive future bug fixes as well.