The asset pipeline is a collection of components that work together. Here's a list of what they might be.Concatenation for merging together many files into one big file.Minification for compressing the contents of a file to make it smaller in size.Pre-compilation for using your language of choice to write CSS or Javascript.Fingerprinting to force reloading of asset changes (i.e., cache busing).

Sure, you have a few extra newlines and semicolons, but the minifier will remove them anyway so no harm.

This semi-colon is added to prevent changing the code behaviour (the famous line ending with parentheses, etc) Most people will use a JS minifier If they don't, a single extra character is unlikely to change much If I'm right about all the above: Why don't we simply always add a semi-colon regardless of what the file ends with?

if we can fix source maps, unconditionally adding ";\n" would be a better solution

I don't understand why this isn't being considered a bigger deal by maintainrs/the community. Don't most Rails developers use SCSS? It's included by default in a new Rails app. Along with sprockets 4. I am mystified how anyone is managing to debug CSS in Rails at all these days, that this issue is being ignored makes sprockets seem like abandonware to me, or makes me wonder if nobody else is using sprockets 4, or what!

Meh... as I said earlier, I think using Webpack is the recommended way now. Another issue is there is no way to generate source maps in production.

sprockets 4 makes Chrome browser identification of SCSS css lines _worse_

But maybe few are still using sprockets at all, for JS or (S)CSS anymore? Hard to say.

But last I have seen comments from DHH, he considered webpack(er) recommended for JS, but Sprockets still the preferred solution for (S)CSS.

I agree about lack of maintenance. It's probably because people use more and more Webpack.

This appears to be an undocumented breaking change. For example, the word "debug" does not appear in the sprockets 4 changelog.

but I still have no idea if I'm writing this new file correctly.

To achieve this, we created a small Compressor which wraps the Uglifier compressor and links the source maps so they are written to disk.

Yes, it's true that it returns a single file, but with the more robust caching in 4.0 it works well enough in my experience.

The semantic has changed a bit as far as I understand. You need to select a pipeline in debug mode.

Sprockets 4.0 treats the ".js.erb" as the extension now. There's no mime type registered to that extension. You need to do: register_mime_type 'application/javascript+ruby', extensions: ['.js.erb']

I used this in the console to find the file and the line of the error (took it from this answer): JS_PATH = "app/assets/javascripts/**/*.js"; Dir[JS_PATH].each do |file_name| puts "\n#{file_name}" puts Uglifier.compile(File.read(file_name)) end

main > Dir["*/assets/javascripts/**/*.coffee"].each { |file_name| puts "\n#{file_name}"; Sprockets::CoffeeScriptProcessor.(filename: file_name, data: File.read(file_name), cache: {}); }

app/assets/javascripts/bootstrapped.js.coffee
NoMethodError: undefined method `config' for nil:NilClass
from /home/tyler/.gem/ruby/2.7.1/gems/sprockets-4.0.2/lib/sprockets/source_map_utils.rb:40:in `format_source_map'

block in Sprockets::CoffeeScriptProcessor.call
sprockets (4.0.2) lib/sprockets/coffee_script_processor.rb, line 24

input[:filename]

Ruby on Rails 6 Note:: With the release of Rails 6 there have been some minor changes made to the default configuration for The Asset Pipeline. In specific, by default Sprockets no longer processes JavaScript and instead Webpack is set as the default. The twbs/bootstrap-rubygem is for use with Sprockets not Webpack.

Another thing I don’t like is the name of the config file manifest.js. Internally Sprockets has the concept of a manifest already Sprockets::Manifest, but the two aren’t directly coupled. We also already have a “manifest” JSON file that gets generated in public/assets/ and has manifest in the name .Sprockets-manifest-140998229eec5a9a5802b31d0ef6ed25.json. I know one is a JS file and one is a JSON file, but it’s a bit confusing to talk about.

Instead of having this confusing maze of lambdas, regexes, and strings, we could, in theory, introduce a single entry point of configuration for Sprockets to use, and in that file declare all assets we wanted to compile. Well, that’s exactly what the manifest.js file is.

Another thing I don’t like: our asset behavior is decoupled from the assets. If you’re mucking around in your app/assets folder, then you have to first know that such a config exists, and then hunt it down in a totally different config folder. It would be nice if, while we’re working in asset land, we didn’t have to mentally jump around.

When Sprockets was introduced, one of the opinions that it held strongly, is that assets such as CSS and JS should be bundled together and served in one file.

When compiling assets with Sprockets, Sprockets needs to decide which top-level targets to compile, usually application.css, application.js, and images.

Sprockets 3 was a compatibility release to bridge Sprockets 4, and many deprecated things have been removed in version 4.