transforms are only applied to files loaded with require()

[mockdeep]

I've added babelify and babel-preset-es2015 to my project with the application.rb configuration:

config.browserify_rails.commandline_options = '-t [ babelify --presets es2015 ]'

This works fine on any files that I require through browserify, but I'm not able to use es2015 syntax in application.js or anything loaded with sprockets requires. Is browserify not running on application.js itself? Might be related to this but wasn't sure.

[cymen]

One hack to try to debug it is to put a comment in your source that is // require or // module.exports. Does that solve it? We would of course want to add a proper fix of detecting es6 (import, etc).

[mockdeep]

I'll give that a try. Do you need to actually detect es6, though? Can't you just pipe all of the assets through the transforms?

[cymen]

Good point -- as long as the initial file that is pulling in the es6 code uses require or somehow triggers browserify, the rest should not need anything. So try putting the work around comment in the initial file(s) that require the rest of your JS code.

[mockdeep]

Hmm, but I've got a require() in my application.js. It causes the required file to run through the transforms, but not application.js.

[mockdeep]

adding // require at the top of application.js did the trick for me.

[mockdeep]

Hmm, nevermind. That is no longer working, nor is // module.exports. Going to keep playing around with it.

[cymen]

After rereading your initial post, the simple solution is to just have application.js require the application and kick it off -- just don't use ES6 or anything in it. That will get you where you want without a lot of messing around. Later on, when you're off the asset pipeline (ideally), you'll have more control over the compilation and can refactor it back into the main file if that is what you want. But why fight such a minor problem?

[mockdeep]

Yeah, we're doing that. We've just got a couple of globals defined in application.js at this point. It's just a surprising issue, and won't necessarily surface if you test on Chrome or Firefox, since they both support a bunch of ES6 features.

Why would we want to get off the asset pipeline, though? Seems like it provides some pretty solid value in terms of precompiling assets.

[cymen]

Because the asset pipeline is becoming an anti-pattern. The only reason browserify-rails exists is because the asset pipeline is keeping JavaScript development about -5 or so years from current best practices. While browserify-rails will work, at a certain point, it's much easier to just go directly to browserify or webpack.

So my perspective is that browserify-rails is best to migrate from legacy JavaScript to CommonJS and then jump off the asset pipeline.

But everyone is free to use it as they see fit of course. There is some benefit to hooking up a page refresh to an asset build. For Ruby developers used to working with Rails, that simple "this is the way it works" makes sense. Although with a Procfile, it's not hard to kick off webpack/browserify watching the assets and recompiling as needed. So I understand there are a variety of use cases.

[mockdeep]

Yeah, I guess I don't see how it's an anti-pattern. It seems like with browserify-rails we get the best of both worlds. We can use npm packages at the same time as having a smooth and automated way to precompile assets. I've looked into dropping it and haven't really seen anything that doesn't require more work on our part.

[cymen]

The issue is browserify-rails will never be quite as good as using browserify or webpack directly. It'll get close but we'll have inevitable bugs and issues. But if it works for your use case and you're happy, then 👍. I definitely understand your view too and my desire to keep browserify-rails working is why I stick around even though I'm no longer using it or Rails in my daily work.

[mockdeep]

Makes sense. Hopefully rails will develop some better ways of integrating with front end oriented toolkits over time. Out of curiosity, how do you manage your process?

[cymen]

I switched employers and am now using webpack directly (which I like -- a prior engineer made that choice and it's working fine, I think browserify is good too). But I'm working on client-side web applications so our backend is typically Ruby-based APIs running Sinatra (with NodeJS to do some service-side rendering).

My prior employer was using browserify-rails for a while but I think they have jumped off the asset pipeline. I'm not sure (I haven't had a chance yet to talk about it in detail with those still working on that project).

One of the issues was the time to run browserify-rails was taking longer particularly on lower end MacBooks (Airs, older 13). With browserify-rails 2.x, I think we have a much better chance of keeping performance high if we can work around the issues with using Sprockets directly instead of using Tilt as an intermediary (as we do on browserify-rails 1.x). In fact, the Sprockets caching should be good enough that we can potentially get rid of browserify-incremental (which is caching browserify builds to try to keep performance up -- but now with 2.x we have caching in Sprockets and caching in browserify-incremental which is likely too complex).

[mockdeep]

I'd definitely be interested in hearing more in detail about how people work without the asset pipeline. So far all I've seen is piles of custom scripts that you have to maintain yourself. I'm more than happy to hand that work off to a framework author if they seem to be doing a relatively competent job of it.

The compile times are the biggest pain point for us, especially because the cache doesn't seem to get invalidated correctly and we end up needing to do rm -rf tmp/cache a lot, and then go grab a cup a joe. Will be upgrading to 2.x shortly, so hopefully that will help.