Defining paths from requirejs.yml does not make modules available for import in development

[najati]

It seems to me that path definitions from requirejs.yml don't do what one would expect, namely, make modules available by name for requiring in other modules.

E.g. this module:

define(function() {
    function Panda(name) {
        this.name = name;
    }

    Panda.prototype = {
        sayHello: function () {
            console.log("Hello, my name is " + this.name + " and I am a panda!");
        }
    };

    return Panda;
})

works when it is located at app/assets/javascripts/panda.js and your application.js looks like

require(['panda'], function (Panda) {
    var panda = new Panda('Bob');
    panda.sayHello();
});

but when you move it to app/assets/javascripts/util/panda.js and create a requirejs.yml that looks like

paths:
  'panda': 'util/panda'

it does not work in development mode. It does work if you precompile and run in production mode with RAILS_SERVE_STATIC_FILES=yup SECRET_KEY_BASE=eleven rails s -e production.

The README leads me to believe that requirejs-rails should enable this to work in development mode.

Sample app here: https://github.com/najati/requirejs-rails-test

Thanks!

[chenxeed]

I believe it's regarding an config config.assets.digest in development.rb,

if your code is not optimized (not running rake assets:precompile) you have to turn the option to false. When you turn it to false, it would generate requirejs.config with defined paths on requirejs.yml.

I set my development.rb digest to false while set staging and production to true.

[najati]

Does that mean that in order for requirejs-rails to work in development that you have to forfeit digest tags on js files, and thus have to start dealing with cached js issues in development?

[chenxeed]

I guess so. Personally I didn't take it as issues for now, since in development mode i disable cache in developer tools.

[najati]

I wouldn't really consider that acceptable, especially given requirejs-rails' claim to stick to rails conventions wherever possible (I'm pretty sure I read that somewhere). Without requirejs-rails, Rails does cache invalidation for you on all instances of your app for all devices, and that's a huge boon. With requirejs-rails you must start worrying about all that again, and I really enjoy not worrying about that.

I haven't looked into the source to modify this behavior, but before I do - would this be a welcome change? And, if so, is this a change that would be relatively straight-forward for one of the experienced contributors?

[carsomyr]

@najati The use case you described should work without digesting. What happens if you take away RAILS_SERVE_STATIC_FILES? With digesting, the problem is that while Rails is fingerprinting files, requirejs-rails doesn't know that you're doing so. This is an anti-pattern anyways, since you don't need cache busting in development mode.

[carsomyr]

@najati Tell you what: If you find that rails new sets config.assets.digest = true in development.rb, I'll honor your request. That's Rails conventions right there. For now, I'm closing.

[najati]

@carsomyr Thanks for the replies! Regarding the second one:

$ rails new toot
 ...
$ grep config.assets.digest toot/config/environments/development.rb
  config.assets.digest = true

So Rails seems to think we should expect digests to work fine in development.

As for the claim that "This is an anti-pattern anyways, since you don't need cache busting in development mode" - I'm trying to understand that. I find the digest/cache busting really handy when switching between browsers, or testing localhost with mobile devices. Is there a reason to not use digests in development? It seems to be a common recommendation, but I'm having trouble understanding it - perhaps this isn't the right forum, but it's relevant context, I suppose.

[carsomyr]

@najati You are right about the config.assets.digest = true setting in development. When I turned it on, however, Rails server up both digestified and raw paths. Perhaps you have some combination of settings that's causing the problem?

[najati]

@carsomyr If you pull the sample app from original post, if doesn't work in development mode. The requirejs.yml file specifies a path for a module, and when application.js requests it, it errors. I would expect the generated require.config that comes out of requirejs_include_tag to include the path for the module defined in requirejs.yml.

You can step through the commits, there's only 8 of them, including the original, untouched Rails app. So it's kinda easy to see the pieces at play.

Thanks!

[carsomyr]

@najati Apologies for skimming your issue and failing to notice that you had a sample app. That helps a lot, and I'll be looking at it.

[csjohn]

@najati Did you ever figure out what was going on here? I'm running into the same problem.

[najati]

Hey John,

We bailed on requirejs-rails after finally accepting our distaste for the way Rails handles javascript in general. We've taken all of our JS out of the asset pipeline and now run webpack along side Rails. We are very happy with the arrangement :-)

I appreciate the effort the requirejs-rails team has put into the bridging the gap, but it still felt like swimming upstream.

Cheers, Najati

On Sat, Dec 19, 2015 at 1:13 PM, csjohn notifications@github.com wrote:

@najati https://github.com/najati Did you ever figure out what was going on here? I'm running into the same problem.

— Reply to this email directly or view it on GitHub https://github.com/jwhitley/requirejs-rails/issues/227#issuecomment-166011217 .