rubysec
gems.rb and gems.locked
It would be great if this useful gem supported the alternative gemfile names as well:
gems.rb(alternative forGemfile)gems.locked(alternative forGemfile.lock)
These alternative names were introduced in 2017.
I've just seen there's an aging PR on this. It may not be the Holy Grail, but given Bundler has a major deprecation warning for the old Gemfile.lock in place for years already, would you consider merging it anyways, @postmodern ? Thanks for considering this!
I haven't seen any deprecation warnings yet and there isn't any immediate plans to remove Gemfile.lock support. However, I will try to add support for detecting gems.locked over Gemfile.lock.
I wrote that in a kinda misleading way: Bundler is not deprecating Gemfile (and my guess: it never will), but a "major deprecations" method prints a warning which suggests that gems.rb is the recommended naming now... or rather since April 2019:
https://github.com/rubygems/rubygems/blob/a9e305432955f56b847881187a7e01a97b6901e3/bundler/lib/bundler/shared_helpers.rb#L144
The advantage of gems.rb is proper syntax coloring which is why other such files are offering similar alternatives now e.g. rakefile.rb or capfile.rb.
(Btw, there's also a typo since gems.rb.locked does not exist, I've already created a PR fixing this.)
I wouldn't highlight this if there were an easy workaround (other than falling back to the ole Gemfile). Adding a symlink doesn't work because Bundler doesn't like to see Gemfile and gems.rb at the same time.
~~Thanks for taking a look!~~ Thanks for the quick fix!
@postmodern Great, looking good! There's just a tiny thing I'd change:
LOCK_FILES = %w[Gemfile.lock gems.locked]
Maybe better flip the two since Bundler uses gems.locked if both are present.
I did some tests and discovered that bundler 2.3.6 would prefer Gemfile.lock over gems.locked, if they both exist.
Weird, another inconsistency of Bundler since the warning suggests otherwise. Never mind, having both is bad to begin with.