33 Matching Annotations
  1. Mar 2021
    1. 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?
    1. 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!
    2. 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.
    3. sprockets 4 makes Chrome browser identification of SCSS css lines _worse_
    4. But maybe few are still using sprockets at all, for JS or (S)CSS anymore? Hard to say.
    5. But last I have seen comments from DHH, he considered webpack(er) recommended for JS, but Sprockets still the preferred solution for (S)CSS.
    6. I agree about lack of maintenance. It's probably because people use more and more Webpack.
    1. To achieve this, we created a small Compressor which wraps the Uglifier compressor and links the source maps so they are written to disk.
    1. 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']
    1. 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

      Didn't work for me because it was actually a .coffee file.

      So I tried something similar with this:

      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'
      

      but it wasn't as trivial to provide the necessary environment that Sprockets wants.

      But that's okay, when better_errors paused on the exception, I just jumped to the

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

      frame and evaluated

      input[:filename]
      

      to figure out which file had failed.

      Obviously this information should be part of the error message itself though!!

  2. Feb 2021
    1. 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.
    1. 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.

      When I first heard of app/assets/config/manifest.js, I was a bit confused too, and assumed/wondered if it was related to the manifest it generates under public.

    2. 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.
    3. 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.
    4. 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.
    1. When compiling assets with Sprockets, Sprockets needs to decide which top-level targets to compile, usually application.css, application.js, and images.
    2. Sprockets 3 was a compatibility release to bridge Sprockets 4, and many deprecated things have been removed in version 4.
  3. Sep 2019