-
That could be explained by the fact that Bundler has to verify the Gemfile.lock file consistency (all the gems are installed). Thus, that's an expected behaviour (that doesn't mean we shouldn't try to improve it; see, for example, Matthew Draper's Gel).
-
Scout Monitoring
Performance metrics and, now, Logs Management Monitoring with Scout Monitoring. Get early access to Scout Monitoring's NEW Ruby logging feature [beta] by signing up now. Start for free and enable logs to get better insights into your Rails apps.
-
Rails developers usually put all the deps in the Gemfile, including dev tools, such as RuboCop. RuboCop is a linter, and linters must be fast. RuboCop itself complies with this statement but running it via Bundler may not.
-
I've been using this technique for a long time for gems development—to speed up CI RuboCop runs (by installing only the linter dependencies). Here is my typical rubocop.gemfile:
-
# gemfiles/rubocop.gemfile source "https://rubygems.org" do gem "rubocop-md", "~> 1.0" gem "rubocop-rspec" gem "standard", "~> 1.0" end
Related posts
-
Any performance/memory issue with Ruby 3.x compared to 2.7?
-
Show HN: AnyCable – real-time for Next.js, open source alternative to PaaS
-
AnyCable v1.3: embedded NATS, StatsD, and more
-
Action cable or AJAX? Performance and solution - what to choose?
-
Kubing Rails: stressless Kubernetes deployments with Kuby