Remove Gemfile. A gem should not commit Gemfile. In this case, a stale dependency on json 1. Fix some broken links …. Closes 4 - Remove link for modern day ruby warrior Closes 7 - Fix dead internal link on security Closes 9 - Remove modern day ruby warrior from resources Closes 14 - Fix link to rubygems mirror repo Closes 5 - Fix broken links from rubyforge on make your own gem page.
More specifically, for gems, version constraints belong in the gemspec. More background on the rationale: Since the gem command only respects the dependency version constraints named in the gemspec, not Gemfile. Explain why not to track Gemfile. Advise not to track track Gemfile. Delete Gemfile. Not needed in source control. We want to use the GitHub pages gem. Removing it ensures that we have the same dependencies that GitHub uses. Cruikshanks mentioned this issue Jun 7, Sign up for free to join this conversation on GitHub.
Already have an account? So why commiting Gemfile. When you run bundle install , bundler will first check Gemfile. That's why, if you app in running properly with current Gemfile. Yeah, we all know that we can quickly create a full database schema in Ruby on Rails thanks to migration. However, remember that a migration file is written in Ruby and there could be error syntax or runtime related to these migrations.
In my experience, I have worked with many different existing projects with broken migration files and we just simply can not create full database schema with rake db:migrate.
In that case, schama. This file contains the latest schema you have when developing your app and it would be automatically updated if your db schema is changed.
In addition, if you look closely at this file, you will notice the following sentence in comment div.
If you are working on a Rails app, then DO check in your Gemfile. If you aren't authoring a package that is intended to be consumed by others e. Make sure to check out the link in the quote, it discusses some pro and cons.
The main pro it mentions is that checking them in ensures that your dependencies are always available, as long as your repository is available. No matter what happens to Bower, GitHub or whatever else would be needed otherwise. No, the package-lock. Instead, I strongly advise:. One of the biggest downside of the npm install command is its unexpected behavior that it may mutate the package-lock.
Also, npm ci requires the existence of a package-lock. There is a strong use-case for being able to trust that the project's dependencies resolve repeatably in a reliable way across different machines. In the past, I had projects without package-lock. While a lot of libraries respect the semvar versioning guideline, you have no guarantee they won't break on a minor upgrade.
Those issue are hard to resolve as you sometimes have to guess what the last working version was. In regards to testing the latest dependencies for your project: This is what npm update is for and I argue that it should be run by a developer, who also runs the test locally, who resolves issue if they may arise, and who then commits the changed package-lock.
If an upgrade fails, they can revert to the last working package-lock. Furthermore, I rarely upgrade all the dependencies at once as that too might require further maintenance but I rather cherry-pick the update I need e.
Which is another reason why I would see it as a manual maintenance step.
0コメント