Devsan wiki

2025-01-28

5 min read

When work with rails scss→ our main goal to load compiled scss to css in builds files.

  • what is the mainfest.js inside assets

The manifest.js file in Rails assets is a special configuration file that declares all the assets (JavaScript, CSS, images) that should be included in your application. Let me explain what each line in your manifest.js does:

  1. //= link_tree ../images

    • This links all images from the app/assets/images directory

  2. //= link_tree ../../javascript .js

    • This links all JavaScript files from the app/javascript directory
    • The .js extension specifies that only JavaScript files should be included

  3. //= link_tree ../../../vendor/javascript .js

    • This links all JavaScript files from the vendor/javascript directory
    • These are typically third-party JavaScript libraries

  4. //= link_tree ../builds

    • This links all files from the app/assets/builds directory
    • This is commonly used for files generated by build tools (like webpack or esbuild)

  5. //= link application.css

    • This specifically links the application.css file
    • This is your main stylesheet file

This manifest file is used by the Asset Pipeline in Rails to determine which assets should be compiled and made available to your application. The Asset Pipeline will use this manifest to:

  • Combine multiple files into one
  • Compress and minify assets
  • Add fingerprints to filenames for cache busting
  • Serve assets efficiently in production

This is a standard setup for a modern Rails application using importmaps or other JavaScript bundling approaches.

Question:- okay so using these configs the staic fringerprints files are generated to public assets Yes, that’s correct! The manifest.js configuration leads to the generation of fingerprinted static assets in the public/assets directory. Here’s how it works:

  1. When you run rails assets:precompile (which happens automatically in production), Rails:
    • Reads this manifest.js file
    • Processes all the specified assets
    • Generates fingerprinted versions in public/assets

For example:

  • An image logo.png might become logo-f761237864.png
  • Your application.css might become application-a2d4c5e6f7.css
  • JavaScript files will be compiled to something like application-b3d5f7g8h9.js

The fingerprint (that random string in the filename) is a hash based on the file’s content. This is crucial for:

  • Cache busting: When you modify an asset, its fingerprint changes, forcing browsers to download the new version
  • Better caching: Since fingerprinted files are content-based, unchanged files keep the same name and stay cached

You can find these generated assets in:

/Users/sandipparida/work/spacelozen/lozen/public/assets/

This is how Rails ensures efficient asset serving in production while maintaining proper cache control.

Question:- but now in public assets there no assets i delted it but still the css are working how?

In development mode, Rails doesn’t require precompiled assets in the public/assets directory. Here’s why your CSS is still working:

  1. In development environment, Rails serves assets directly from your app/assets, app/javascript, and other source directories specified in the manifest.js

  2. The Asset Pipeline processes these files on-the-fly when:

    • You make a request to your application
    • The assets are compiled in memory
    • They are served directly without writing to public/assets

This is different from production where:

  • Assets must be precompiled (rails assets:precompile)
  • Static files must exist in public/assets
  • Serving is done through the web server (nginx/apache) directly from public/assets

To verify this, you can:

  1. Check your browser’s developer tools
  2. Look at the Network tab
  3. Find your CSS file request
    • In development, you’ll see it served from /assets/application.css but it’s actually coming from your source files, not public/assets

This on-the-fly compilation in development makes it easier to work on your assets without having to precompile them every time you make a change.

Question in my dev env its requested to this :-http://localhost:3000/assets/application-d3e7bd71.css

, but in my project there no file named this

This is normal behavior in Rails development! Let me explain what’s happening:

  1. The application-d3e7bd71.css is a fingerprinted filename that Rails generates dynamically in development. The -d3e7bd71 part is a hash based on your CSS content.

  2. In development, Rails uses Sprockets (Asset Pipeline) to:

    • Compile your CSS files on-the-fly
    • Generate a virtual fingerprinted filename
    • Serve the content through the /assets endpoint
    • Cache the compiled assets in memory

Your actual source files are in:

  • app/assets/stylesheets/application.css (or .scss)
  • Any other CSS files imported by your application.css

The fingerprinted URL is generated for cache-busting purposes, but in development:

  • The file doesn’t physically exist on disk
  • It’s served virtually by the Asset Pipeline
  • The fingerprint changes when you modify your CSS

This is why you won’t find application-d3e7bd71.css in your project files, but your styles still work perfectly. If you want to see the actual source files that make up this compiled CSS, look in your app/assets/stylesheets directory.

Question:- but i am using propshaft

Yes, I notice you’re using Propshaft instead of Sprockets (the traditional Asset Pipeline). This explains the asset behavior we discussed earlier!

Propshaft is Rails’ modern asset pipeline that:

  1. Is lighter and faster than Sprockets
  2. Uses a simpler fingerprinting approach
  3. Works differently in development mode

With Propshaft:

  • In development, it serves assets through Rails’ built-in server
  • It still generates fingerprinted URLs (like application-d3e7bd71.css)
  • But instead of compiling on-the-fly like Sprockets, it watches your assets for changes and updates them when needed
  • The fingerprinted assets are kept in memory during development

This is why you see the fingerprinted URL (application-d3e7bd71.css) even though the file doesn’t exist on disk. Propshaft handles this differently from Sprockets, but the end result is similar - your assets are served efficiently in development without needing to manually precompile them.

In production, Propshaft will still generate physical fingerprinted files in public/assets when you run rails assets:precompile.

Graph View