Remove lazy-lock.json from .gitignore

[mattgallagher92]

It's recommended to have lazy-lock.json under version control. See https://lazy.folke.io/usage/lockfile.

The kickstart team have previoulsy agreed that it should be in version control (see #433), and removed it from .gitignore, but it was subsequently re-ignored without justification. See 8b5d48a.

Having the lockfile available would have helped me to revert to a previous version after my treesitter and lsp integration started misbehaving.

[mattgallagher92]

P.S. Thanks for making and maintaining kickstart! It's made getting started with neovim much easier than it would have been ❤️

[dam9000]

IMO lazy-lock.json should be in .gitignore for the kickstart repo.
You can add it to version control in your own clone.
If lazy-lock.json would be in kickstart git repo, it would soon be outdated unless someone has the will to update it regularly.

[ro0gr]

Might be a good idea to highlight the topic in the README recommended step section, so a newcomer is aware of the concern at least.

[mattgallagher92]

I understand your concern @dam9000, but I disagree. Kickstart.nvim is meant to be a starting point for someone's config, particularly for beginners. Ignoring the lockfile is not a good starting point.

@ro0gr's suggestion somewhat makes up for this. However, I think that a better solution might be to suggest that people use Lazy to sync their plugins immediately after installation. That way, it doesn't matter if the lockfile is out of date when someone clones, and they begin to get familiar with Lazy straight away.

[iton0]

I agree with @dam9000 point that it would become a hassle to keep the lazy-lock.json updated. The other issue I could see arising from this is merge conflicts between the remote and local lazy-lock.json. I even looked at Lazy.vim and NvChad and neither have lazy-lock.json in their repos. @ro0gr suggestion I feel would be the most beneficial for beginners by letting them know about lazy-lock.json and maybe even linking a reference to the lazy.nvim doc about it.

[mattgallagher92]

Thanks everyone for your input 🙂 it's great to have such an active community providing their expertise!

I'll leave this PR open for a few days in case anyone else wants to weigh in but, given the consensus seems to be against my suggestion, I don't mind someone with the privileges to do so to close it without merging 🙂

If that happens, @ro0gr's suggestion is probably worth implementing!

[VlaDexa]

Including a lock file would help with issues like #1079, but when most of our dependencies are targeting the latest commit it will not only make it more bothersome to maintain the repo (deciding how often to update it and what dependency changes are worth including), but will probably create an issue where every PR would update this file, which is almost always an unrelated change.

[mattgallagher92]

Thanks all. I've made #1090 which implements the suggestion from @ro0gr; will close this PR.