-
Notifications
You must be signed in to change notification settings - Fork 92
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
transforms are only applied to files loaded with require()
#124
Comments
One hack to try to debug it is to put a comment in your source that is |
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? |
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. |
Hmm, but I've got a |
adding |
Hmm, nevermind. That is no longer working, nor is |
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? |
Yeah, we're doing that. We've just got a couple of globals defined in Why would we want to get off the asset pipeline, though? Seems like it provides some pretty solid value in terms of precompiling assets. |
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. |
Yeah, I guess I don't see how it's an anti-pattern. It seems like with |
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. |
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? |
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). |
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 |
I thought a little note about using transforms would be nice for people, along with an example of a simple way to add ES6 support. a related issue here: browserify-rails#124
I've added
babelify
andbabel-preset-es2015
to my project with theapplication.rb
configuration:This works fine on any files that I
require
through browserify, but I'm not able to usees2015
syntax inapplication.js
or anything loaded with sprockets requires. Is browserify not running onapplication.js
itself? Might be related to this but wasn't sure.The text was updated successfully, but these errors were encountered: