Module: Jets::Bundle

Extended by:
Bundle
Included in:
Bundle
Defined in:
lib/jets/bundle.rb

Overview

Named Bundle vs Bundler to avoid having to fully qualify ::Bundler

Instance Method Summary collapse

Instance Method Details

#bundler_enabled? ⇒ Boolean

Also check for Afterburner mode since in that mode jets is a standalone tool.

Returns:

  • (Boolean) 


70
71
72
 
# File 'lib/jets/bundle.rb', line 70

def bundler_enabled?
  !Jets::Turbo.afterburner? && gemfile?
end

#bundler_groups ⇒ Object 



78
79
80
 
# File 'lib/jets/bundle.rb', line 78

def bundler_groups
  [:default, Jets.env.to_sym]
end

#gemfile? ⇒ Boolean

Returns:

  • (Boolean) 


74
75
76
 
# File 'lib/jets/bundle.rb', line 74

def gemfile?
  ENV['BUNDLE_GEMFILE'] || File.exist?("Gemfile")
end

#handle_error(e) ⇒ Object 



50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
 
# File 'lib/jets/bundle.rb', line 50

def handle_error(e)
  puts e.message
  puts <<~EOL.color(:yellow)
    WARNING: Unable to require "bundler/setup"
    There may be something funny with your ruby and bundler setup.
    You can try upgrading bundler and rubygems:

        gem update --system
        gem install bundler

    Here are some links that may be helpful:

    * https://bundler.io/blog/2019/01/03/announcing-bundler-2.html
    * https://community.rubyonjets.com/t/jets-1-9-8-install-issue-bundler-setup-missing/185/2

    Also, running bundle exec in front of your command may remove this message.
  EOL
end

#jets_project? ⇒ Boolean

Returns:

  • (Boolean) 


82
83
84
 
# File 'lib/jets/bundle.rb', line 82

def jets_project?
  File.exist?("config/application.rb")
end

#require ⇒ Object

Bundler.require called when environment boots up via Jets.boot. This will eagerly require all gems in the Gemfile. This means the user will not have to explictly require dependencies.

It also useful for when to loading Rake tasks in Jets::Commands::RakeTasks.load! For example, some gems like webpacker that load rake tasks are specified with a git based source:

gem "webpacker", git: "https://github.com/tongueroo/webpacker.git"

This results in the user having to specific bundle exec in front of jets for those rake tasks to show up in jets help. Instead, when the user is within the project folder, jets automatically requires bundler for the user. So the rake tasks show up when calling jets help.

When the user calls jets help from outside the project folder, bundler is not used and the load errors get rescued gracefully. This is done in Jets::Commands::RakeTasks.load! In the case when user is in another project with another Gemfile, the load errors will also be rescued.



41
42
43
44
45
46
47
48
 
# File 'lib/jets/bundle.rb', line 41

def require
  return unless jets_project?
  return unless bundler_enabled?
  Kernel.require "bundler/setup"
  Bundler.require(*bundler_groups)
rescue LoadError => e
  handle_error(e)
end

#setup ⇒ Object

Looks like for zeitwerk module autovivification to work ‘bundle exec` must be called. This allows zeitwork module autovivification to work even if the user has not called jets with `bundle exec jets`. Bundler.setup is essentially the same as `bundle exec` Reference: www.justinweiss.com/articles/what-are-the-differences-between-irb/

The Bundler.setup is only necessary because we use Bundler.require after require “zeitwerk” is called.

Note, this is called super early right before require “zeitwerk” The initially Bundler.setup does not include the Jets.env group. Later in Jets::Booter, Bundle.require is called and includes the Jets.env group.



17
18
19
20
21
22
23
24
 
# File 'lib/jets/bundle.rb', line 17

def setup
  return unless jets_project?
  return unless bundler_enabled?
  Kernel.require "bundler/setup"
  Bundler.setup # Same as Bundler.setup(:default)
rescue LoadError => e
  handle_error(e)
end