How to get full JS/CSS source to inline (e.g. Mailer templates or PDF generation)

[zealot128]

I've been struggling to use Vite to inline the javascripts/stylesheets, especially for:

• Mailers: using foundation-email to enhance stylings
• Or: PDF generation via WKHTMLToPdf
• Or: generating charts offline by the server, e.g. D3/Highcharts by running a chrome instance and making screenshots

For all those purposes it is desired to inline the full Javascript/Stylesheet source.

We've dabbled around with:

ViteRuby.instance.manifest.resolve_entries(entrypoint)[:scripts].map do |path|
  File.read(Rails.root.join('public', *path.split('/')))
end.join("\n")

This seems to work for the stylesheets so far, but the javascript is difficult to inline, because of ESM, wrapping it with a script produces Uncaught SyntaxError: export declarations may only appear at top level of a module, using the script type=module brings Uncaught SyntaxError: duplicate export name 'A'

Has any of you any experience successfully inlining the Javascript?

[ElMassimo]

Hi Stefan! @zealot128

Regarding the styles for mailers, using premailer-rails might also be a good option.

---

I assume inlining JS is only relevant for the third use case:

generating charts offline by the server, e.g. D3/Highcharts by running a chrome instance and making screenshots

Could you elaborate on why is it desirable to inline the JS?

---

The following error suggests that you are combining separate ESM files into a single one:

Uncaught SyntaxError: duplicate export name 'A'

Combining modules into a single file is not a trivial task and requires full analysis, a task that is perfect for Rollup (Vite). Alternatively, you could use one of these hacks to inline each file separately.

I'd recommend experimenting by either:

• Setting inlineDynamicImports: true which will work if you have a single entrypoint, and should result in a single file that can be inlined safely in a normal script tag.

  const inlineBuild = process.env.VITE_RUBY_ENTRYPOINTS_DIR === 'bundle'
  
  export default defineConfig({
    build: {
      rollupOptions: {
        output: inlineBuild && {
          inlineDynamicImports: true,
          format: 'iife',
        },
      },
    },
    ...

  If you have more than one entrypoint, you could create a separate folder with a single file (app/frontend/bundle/main.ts), and using VITE_RUBY_ENTRYPOINTS_DIR to run a separate build:

  VITE_RUBY_ENTRYPOINTS_DIR="bundle" VITE_RUBY_BUILD_CACHE_DIR="tmp/cache/bundle" VITE_RUBY_PUBLIC_OUTPUT_DIR="bundle" bin/vite build
  

  This is an easy way to reuse vite.config.ts almost entirely.

• Skippingvite-plugin-ruby, and manually specifying your entrypoints in build.lib, and configuring their output as iife.

  import RubyPlugin, { projectRoot } from 'vite-plugin-ruby'
    
  const root = resolve(projectRoot, 'app/frontend')
  
  export default defineConfig({
    root,
    resolve: {
      alias: {
        '@': root,
        '~': root,
      },
    },
    build: {
      lib: {
        name: 'bundle',
        entry: 'entrypoints/application.ts',
        formats: ['es', 'iife'],
      },
      rollupOptions: {
        output: {
          inlineDynamicImports: true,
        },
      },
    },

You can toggle between a normal build and an iife build by using environment variables within your vite.config.ts, or using separate config files and passing a --config flag to vite build.

[zealot128]

Thank you for your response,

Regarding the styles for mailers, using #93 (comment) might also be a good option.

Yes, that's what we are doing, too. But premailer needs to access the assets and open it. AFAIK Premailer just used the Rails internal asset resolving, then opens the file on disk and inlines it. Or do you ever use it together with Vite stylesheets without any tuning?

But apparently, CSS inlining works with the snippet I've posted above more or less ok. Premailer can then take over and apply those styles to each DOM element.

I assume inlining JS is only relevant for the third use case:

Not in this particular use case, but in general there were many cases were I've build PDFs that executes Javascript (A PDF with Javascript charts for example, reusing existing React/Vue components for "print out" views etc.)

Could you elaborate on why is it desirable to inline the JS?

Wkhtmltopdf and Wkhtmltoimage or the most common tools to do this, it's also used by WickedPDF. They usually don't work very well with linked assets and recommend to inline all JS+CSS (which WickedPdf does for example) into the html that you want to convert. Our current migration from Webpacker to Vite stumbled upon this issue, where previously we just inlined the assets from the packs folder (e.g. wicked_stylesheet_link_tag etc.) and this case was the only one we couldn't easily migrate, that's why I wanted to ask the community if there are any other solutions.
We are already using a Ferrum/Chrome, so it might be possible that we just link the assets in the normal way, just need to adjust some stuff (e.g. development/test/staging systems are locked down and assets are not open to access without Authorization)

Combining modules into a single file i [...]

Thanks, I will look into those methods!

[ElMassimo]

Or do you ever use it together with Vite stylesheets without any tuning?

Yes, premailer should be able to pick up the link tags rendered by using the standard Vite Ruby tag helpers.

See this PR for a way to get HMR during development.

[zealot128]

Yes, premailer should be able to pick up the link tags rendered by using the standard Vite Ruby tag helpers.

AFAIK Premailer uses 3 different strategies Link: Network (asking the dev-server), File-System (loading from manifest) or Asset pipeline. So I guess it would use "network" in vite's case in development and file-system in production?

For tests, especially on CI-system that would probably mean one has to precompile assets beforehand, because in CI there is no Vite server running.

Like I've said, CSS is not the big issue, we can also inline it manually with minimal code anyways, but JS ESM stuff is still seemlingly hard. I guess, the easiest option is to say byebye to wkhtmltopdf and -image and look more into Ferrum or Puppeteer and let it run the full JS stack with browser modules. For images (Screenshots of charts) that would be a good solution, but for a PDF with Javascript it get's tricky, because WKTHMLToPdf does a lot of important stuff (outline, auto-links, header/footer, line-numbers, TOC links) which I am not sure Puppeteers PDF. Or for those JS don't use Vite but "normal" or "new" asset pipeline (Sprockets, Propshaft etc.) and thus can rely on wicked_pdf's inlining helpers.

Thanks for your help and work on this Gem!

[ElMassimo]

So I guess it would use "network" in vite's case in development and file-system in production?

Yes, and it would be file-system in testing as well.

one has to precompile assets beforehand

Vite Ruby will automatically compile assets when accessing the manifest—such as when using tag helpers—if autoBuild is enabled, which it is by default.

---

For WKTHMLToPdf it sounds reasonable to do an extra build in iife format with inlineDynamicImports: true, that would allow you to safely inline JS without having to switch to a different tool for PDF generation.

If you use a different cache and public output dir, it would not conflict with your "standard" build, so your main app can use the standard tag helpers, while in WKTHMLToPdf you manually read and inline the single-file JS and CSS output from the iife build.

Feel free to drop a message with an update later down the line, curious to see what you end up with 😃

[rockwellll]

Hi, sorry for chiming in so late. I've been working on your guidelines here but when I try to <%= vite_stylesheet_tag 'application.scss' %> I get the following error, File with URL "/vite-dev/entrypoints/application.scss" could not be loaded by any strategy..

Here's how my config looks like,

// vite.config.ts

import { resolve } from 'path'
import { defineConfig } from 'vite'
import ViteRails from 'vite-plugin-rails'
import Vue from '@vitejs/plugin-vue'
import tailwindcss from 'tailwindcss';


export default defineConfig({
  plugins: [
    ViteRails(),
    Vue(),
  ],
  define: {
    global: 'window'
  },
  resolve: {
    alias: {
      '@assets': resolve(__dirname, 'app/assets'),
    },
  },
  css: {
    postcss: {
      plugins: [tailwindcss("./app/javascript/entrypoints/stylesheets/tailwind.config.js")],
    },
  },
})

// vite.json
{
  "all": {
    "sourceCodeDir": "app/javascript",
    "watchAdditionalPaths": [
      "app/assets"
    ],
    "devServerConnectTimeout": 3000
  },
  "development": {
    "autoBuild": true,
    "publicOutputDir": "vite-dev",
    "port": 3036
  },
  "test": {
    "autoBuild": true,
    "publicOutputDir": "vite-test",
    "port": 3037
  }
}

And here's the directory, if I do for example javascript_link_tag 'application it works without issues, but with the sass extension it seems it's not being able to find it. Thanks in advance.

[zealot128]

Finishing up this question; In the end we decided that we don't need Vite-processed JS in our PDF's. That usually only amounts to very minuscule amount, like Page Numbers and stuff, so it's better to keep inlined or in a separate js file to embed, irrespective of which PDF generator we use (Wicked, Grover, Chrome etc.).

But using CSS is not very difficult; the best way, is just inline everything into the document, like with a little helper (used/tested on Vite4/ViteR 3.3):

module ApplicationHelper
  def vite_pdf_stylesheet_link_tag(vite_asset)
    if ViteRuby.instance.manifest.dev_server_running?
      raise NotImplementedError, "vite_pdf_stylesheet_link_tag is not supported in development mode"
    end
    entry = vite_manifest.resolve_entries(vite_asset)
    css_files =
      if vite_asset[/css|scss/]
        entry[:scripts]
      else
        entry[:stylesheets]
      end

    safe_join(
      css_files.map do |css_file|
        output_path = "./#{ViteRuby.instance.config.public_dir}/#{css_file}"
        tag.style File.read(output_path)
      end
    )
  end
end

if you pass it a entrypoint scss/css file:

= vite_pdf_stylesheet_link_tag 'pdf.scss'

It will inline the file,
If you pass it a Javascript entrypoint:

= vite_pdf_stylesheet_link_tag 'dashboard.js'

It will collect all the sidecard css files that the entrypoints imports - Directly stolen from Vite's own vite_javasvript_link_tag :)

[zealot128]

Our second use case was a "widget.js" that is hotlinked from customer's websites. So having a changing asset path via content-hash and using js-modules is not possible here.

We decided to use ElMassimos' Hack:

const inlineBuild = process.env.VITE_RUBY_ENTRYPOINTS_DIR === 'widget/entrypoints'

...

  build: {
    rollupOptions: {
      output: inlineBuild && {
        inlineDynamicImports: true,
        format: 'iife',
      },
    },

having a single extra entrypoint in: app/frontend/widget/entrypoints/widget.js

Small wrapper script:

#!/bin/bash

# ./bin/build-widgetjs
rm -rf tmp/widget
export VITE_RUBY_ENTRYPOINTS_DIR="widget/entrypoints" 
export VITE_RUBY_BUILD_CACHE_DIR="tmp/cache/bundle" 
export VITE_RUBY_PUBLIC_OUTPUT_DIR="../tmp/widget" 
set -e
bin/vite build
mv tmp/widget/assets/widget-*.js vendor/assets/javascripts/widget.js

...

and a controller action that maps "/widget.js" to the most recent widget.js:

class SomeController < AC
  def widget
    path = "vendor/assets/javascripts/widget.js"
    fresh_when etag: path
    respond_to do |f|
      f.js {
        send_file path, type: 'application/javascript', disposition: 'inline'
      }
    end
  end

now, our customers can just link FQDN.com/widget.js into their site it stuff works!

Thanks @ElMassimo for the big help so far!