Merge Opal load path and ruby load path

[adambeynon]

Opal uses its own load path, which is shared with sprockets, to manage locations to search for opal libraries. This is awkward as gems built for opal cannot simply use a standard gem setup, they need a separate opal/ directory for opal code, and lib/ directory for code to run under mri. Somewhere inside lib/ a gem must register itself with opal to add the opal/ directory to the load path. All very ugly when ruby has a load path doing this for us.

The problem with just having the same load path is that gems added with bundler will get auto required unless explicitly told not to. Considering a lot of code in these gems are designed for the browser and probably have lots of xstrings, bad things could happen. A workaround would be for the main/root file in an opal gem to wrap its require statements in a simple platform check, e.g. vienna.rb:

# lib/vienna.rb
require 'vienna/version'

if RUBY_ENGINE == "opal"
  require 'vienna/dom_stuff'
  require 'vienna/foo'
end

All very simple, and it wont break anything.

Thoughts, comments, suggestions etc.

[elia]

The other issue is that you may to have a file with the same name but with different impl for the browser, not to mention corelib and stdlib.

What we can do about ugly code is to let opal search for gems with the opal dir and automatically add those dirs to its loadpath. This way we still have ugly code, but it's segregated in one place.

[adambeynon]

Yes, unfortunately I think we would still need to have some custom prioritised paths for corelib/stdlib etc. I wonder how dangerous it would be if when we create the sprockets instances (or add the paths onto rails' asset pipeline) that we add all opal load paths, and then add all ruby load paths afterwards. That way, any custom opal paths will be prioritised by sprockets, and then any libs/gems that do not need special treatment would just get added as expected.

[elia]

Sounds still to hacky and dangerous to me

[ryanstout]

So correct me if I'm not understanding this correctly, but would the path thing be an issue since opal could setup the path to corelib and stdlib, so then the only other issue would be when you have a separate gem that requires different files for opal right? And in that case it seems like the gem developer could handle it right? Either way a gem that wasn't designed for opal and requires custom code is going to take some hacking to get to work, correct?

[elia]

After a bunch of time having the shared lib/ setup in opal-jquery I can say using a separate opal/ dir is still less confusing, and it's good to make explicit when some code is shared by the two platforms.