I'm trying to use these gists to get Sprockets 2.0beta to work with a Rails 3.0.5 app in a similar way to how it works natively in Rails 3.1. Failing thoroughly so far--my app is finding the correct routes and files, and loading the initializer that extends Sprockets::Environment, but it's not parsing the //= require 'phu' lines in my application.js.
Can anyone enlighten me about Sprockets 2 with Rails 3.0?
I have used the same gists as a basis, and it works fine. I have made some changes though.
Maybe you can try that, see if it helps: https://gist.github.com/1112393
ps: I guess you solved it yourself since it's been a month...
I personally have another problem: How to use Sprockets 2 with Rails 3.0.x (how to use precompiled assets)
If you solved it already, or found another way to make this efficient on production, could you help me? Thanks.
Related
I just started a new rails 7 project with --css bootstrap, but I'm finding that starting the server with bin/dev the compiled css does no longer (as in previous rails versions) output a comment with the file name and line number of the file where to find each scss class definition.
I'm actually rather confused on how the new rails works with scss and css, it doesn't seem that the css is compiled at all. I couldn't find any good resources for understanding how it works. any suggestions?
Thanks,
Sprockets doesn't seem to generate sourcemaps by default.
You can try opening up this file:
config/environments/development.rb
And adding the line:
config.assets.debug = true
What are the contents of you din/dev file?
Also rails 7 got rid of webpack:
Webpacker has served the Rails community for over five years as a
bridge to compiled and bundled JavaScript. This bridge is no longer
needed for most people in most situations following the release of
Rails 7. We now have three great default answers to JavaScript in
2021+, and thus we will no longer be evolving Webpacker in an official
Rails capacity.
Rails 7 now uses importmaps, so depending on your gem file you might have to use css-bundling. Look into that and dartsass along with propshaft, which replaces sprockets which they are thinking about doing in the future, to get a better idea.
Will Propshaft replace Sprockets as the Rails default? Most likely,
but Sprockets need to be supported as well for a long time to come.
Plenty of apps and gems were built on Sprocket features, and they
won't be migrating soon. Still working out the compatibility story.
This is very much alpha software at the moment.
I am upgrading my app from Rails 5.0 to 5.1, and there is one thing I can't find being mentioned anywhere - usage of Webpacker to process ActionCable JavaScript files.
I realise that Webpacker and the asset pipeline are supposed to work side by side, but now that we have Webpack build into Rails it would be a waste not to use it for files located in assets directory (which is where ActionCable lives), yet I can't find any information on how to do that.
I'm specifically interested in Babel, so I could use ES6. Any ideas?
The problem here is that you need to replace the ActionCable implementation of rails, which is written for sprockets with something that is written in module syntax, to make proper use of webpacker.
Specifically this line in your cable.js
require action_cable
Everything else should be easily portable.
There seem to be a couple of implementations for ActionCable and modules around:
https://www.npmjs.com/search?q=keywords:ActionCable
Specifically this looks exactly what you are searching for:
https://www.npmjs.com/package/actioncable-modules
There seems to be some movement on the side of Rails to use Webpacker as a complete sprocket replacement in Rails 6, so it might be worth waiting, instead of creating something that builds on third party modules.
Basically, I am in the same boat as this question:
Rails 4 asset compilation is VERY slow (>1min) in dev mode. How to troubleshoot?
But instead of using Bootstrap, I'm using Susy 2 with SASS 3.3 and Rails 4.1 (but not Compass). I'm using the Sprockets 'require' in my application.js manifest, and it's not causing any problems...the snail's pace only happens when I make a change to any SASS file. At the moment I'm needing to use the #import rule in my stylesheet manifest.
I have tried variations on the 'require'/'#import' combination, and they have helped a little bit, but I do have a lot of SASS files and I'd love to just have an application.css.scss manifest that uses SASS's compilation method instead of including a 'global' file with an #import at the top of each SASS file.
I'm wondering whether it could have something to do with the current Sprockets/sass-rails gem issues; during compilation I get a lot of
Warning. Error encountered while saving cache 6b6acdc6a4d802b749fef26e565bbfe3caa60193/style.css.scssc: can't dump anonymous class #<Class:0x007ff59c2c8870>
I'd try moving back to SASS 3.2 if I could and still use Susy 2.
I'd be OK with not using the Asset Pipeline if I could be sure that the app would still play nice with Heroku when pushing to staging/production. I am familiar with both Grunt and Gulp, less so with what using Grunt/Gulp instead of the AP would do to my Rails app.
On the one hand, I'm glad that I'm not alone with this problem, but on the other...I'd love to find a way out of it, if anyone has some suggestions to share! Thanks in advance, SO community!
So I installed Ruby on Rails(first time) and got down to starting a new project and a server. So as expected there was an error on running the Rails server command. Some gems needed to be installed, apparently. The bundle install command didn't work for some wierd ssl issue. So I decided to do it all
manually.
What strikes me as odd is that there's a gem for jQuery: jquery-rails. I don't understand the point of this, really. Why not simply download the jquery file and put it in public.
What's the point of having a gem here.
Is it simply convinience or is there another important reason behind it?
Jquery-rails does 2 things. First of all it bundles the appropriate version of jquery. I consider this only a convenience for jquery itself. For something like jquery-ui, jquery-ui-rails does a lot more: since jquery-ui is modular, that gem will serve to clients only the bits of jquery-ui you are using.
The other thing in jquery-rails is jquery-ujs. This is javascript that makes things such as passing the :remote => true option to form_for work. It used to be that rails itself contained a version of this for prototype, but with rails 3 this was extracted from rails to make it easier to use other javascript libraries than rails' previous default of prototype
I think this is a good idea, because it makes JQuery available as a versioned dependency.
If you need to update JQuery, you just have to change the version at one place in your app, and every page that needs it will use the new version.
And based on its homepage, there's also a test helper that you can use in your tests.
I just upgraded my project to rails 3.1 since I saw the sass feature and the moving of public folder files to the assets folder and considered these major changes I should adjust to, especially the sass feature which is pretty cool.
however, when looking at heroku, i came across this post detailing what to do to get rails 3.1 working on heroku: http://devcenter.heroku.com/articles/rails31_heroku_cedar#getting_started
my app hasn't launched yet but I do intend to be on heroku and from the looks of that document, getting rails 3.1 to run on heroku sounds a little messy, where the assets folder is being created in the public folder.. when it has its own place now in 3.1.
what are everyone else's thoughts on this? i like to keep my code clean and am thinking if I should go back to rails 3.0.
maybe I missed something or a useful reason for doing this here, or am not interpreting this right, because this public folder precompile thing sounds so redundant to me.
In short, is having Rails 3.1 on Heroku good? Or should I go back to Rails 3.0
The asset pipeline is not required, and you can simply not use it if you don't want to.
Definitely keep Rails 3.1 for your app. You will have a much easier time upgrading for things you like in the future, and will have better security updates as the older versions eventually won't be maintained.
I'd recommend using the asset pipeline, and you can read more about it in the guide. http://guides.rubyonrails.org/asset_pipeline.html
If you don't want to use it though in your config/application.rb file change:
config.assets.enabled = true
to
config.assets.enabled = false
You'll probably also want to remove the assets gem group from your Gemfile as well.
Having your assets compiled into public is nothing to worry about. This is a sensible idea as you don't want to have to recompile your assets for every request.
Rails 3.1 has a number of advantages, however ultimately it's your decision, but I certainly wouldn't be fretting about asset compilation.
If youre app if using Jquery-UI (jquery being the new default in 3.1) then for sure just disable the asset pipeline and use 3.1. asset pipeline breaks jquery-ui anyway.