Support "documents" as assets out of the box

[G-Rath]

I recently discovered there's a little bit of work required to support serving "document" assets such as PDFs via Shakapacker that allows nested file paths - effectively the config ended up being:

'use strict';

const Dotenv = require('dotenv-webpack');
const { dirname } = require('path');
const {
  config: { source_path: sourcePath },
  generateWebpackConfig
} = require('shakapacker');

const options = {
  module: {
    rules: [
      {
        test: /\.(pdf)$/,
        type: 'asset/resource',
        generator: {
          filename: pathData => {
            const folders = dirname(pathData.filename)
              .replace(`${sourcePath}`, '')
              .split('/')
              .filter(Boolean);

            const foldersWithStatic = ['static', ...folders].join('/');

            return `${foldersWithStatic}/[name]-[hash][ext][query]`;
          }
        }
      }
    ]
  },
  plugins: [new Dotenv()]
};

module.exports = generateWebpackConfig(options);

This is actually the exact configuration Shakapacker uses internally except they have a different test which is static - the key thing is the filename part.

Say we have a file at app/frontend/documents/forms/declaration_form.pdf:

• without filename we'd have to do asset_pack_path("declaration_form.pdf") and we'd get something like packs/123abc.pdf
• with filename we are able to do asset_pack_path("documents/forms/declaration_form.pdf") and we'd get something like packs/static/documents/forms/declaration_form-123abc.pdf

We don't use these kind of assets in most apps, but it feels easy enough to at least have this documented or included as a code comment in our default webpack config to save people some time.

[lukeify]

Discussed at Ruby Guild on 3 November 2023 and needs more exploration. One concern raised was that it may become mostly unused in most of our apps and adds some complexity to our webpacker setup.

One step is to explore removing sprockets. Ticket to be created for that.