Coder Legion - Recent posts tagged nuxt

I Kept Rebuilding PDF Features in Vue 3, So I Built vue-pdf-export

Fri, 04 Sep 2026 00:10:12 +0000

Hey everyone 👋

I recently released vue-pdf-export, an open-source Vue 3 + TypeScript library for generating PDFs directly in the browser.

I built it after repeatedly needing the same PDF features across different Vue projects and wanting one reusable solution instead of rebuilding the same logic each time.

What it supports

Some of the main features include:

Canvas and selectable-text PDF rendering
Automatic and manual pagination
Preview, download, and browser print
Headers and footers
Watermarks and page targeting
Clickable PDF links
Password protection and permissions
PDF metadata and compression
Progress reporting and cancellation
Large-document rendering
Blob, ArrayBuffer, Base64, and PDF data URL outputs
data-pdf-ignore for excluding UI elements from exports
Export-only page and body styling
Nuxt 3 and Nuxt 4 SSR-safe package imports

The package also has compatibility coverage for npm, pnpm, Yarn, Yarn Plug'n'Play, and Bun.

Installation

npm install vue-pdf-export

Basic usage

<script setup lang="ts">
import { ref } from 'vue'
import { Html2Pdf } from 'vue3-pdf-export'
import 'vue3-pdf-export/style.css'

const pdf = ref<InstanceType<typeof Html2Pdf> | null>(null)

async function generate() {
  await pdf.value?.generatePdf()
}
</script>

<template>
  <button @click="generate">
    Generate PDF
  </button>

  <Html2Pdf
    ref="pdf"
    filename="example.pdf"
    :preview-modal="true"
  >
    <template #pdf-content>
      <main>
        <h1>Hello from Vue</h1>
        <p>This content will be exported to PDF.</p>
      </main>
    </template>
  </Html2Pdf>
</template>

Canvas or selectable text

Use Canvas rendering when HTML/CSS fidelity is the priority:

<Html2Pdf render-mode="canvas">

Or use selectable-text rendering when users need to select, search, and copy text from the generated PDF:

<Html2Pdf render-mode="text">

This makes the package useful for both highly visual layouts and text-heavy documents such as reports, invoices, statements, and documentation.

The idea is to let developers choose between maximum browser-style fidelity and real selectable PDF text depending on their use case.

Programmatic output

The generated PDF can also be used directly in your application:

const blob = await pdf.value?.generatePdf()
const buffer = await pdf.value?.generatePdfArrayBuffer()
const base64 = await pdf.value?.generatePdfBase64()

This is useful when you want to upload, store, preview, or pass the PDF to another API instead of immediately downloading it.

Nuxt support

The package is designed so importing it does not crash Nuxt SSR.

Actual PDF generation still happens in the browser, so a typical Nuxt integration can use ClientOnly or lazy client-side rendering when needed.

Pagination

The package supports both automatic and manual pagination.

For an explicit manual page break:

<div class="html2pdf__page-break"></div>

There are also options for keeping elements together and avoiding unwanted page breaks.

Large-document rendering

Large PDFs were one of the areas I wanted to improve significantly.

Canvas rendering can become expensive when a browser attempts to create one extremely tall canvas for an entire document.

vue3-pdf-export can now render paginated Canvas documents incrementally, page by page, instead of depending on one giant full-document capture.

In one benchmark fixture, the previous long-document capture surface was around:

99.96 million pixels

while incremental rendering kept the maximum capture surface around:

1.74 million pixels per page

That is approximately a 98.26% reduction in peak capture-surface geometry for that fixture.

This is specifically a rendering-surface measurement, not a claim that total browser memory always drops by the same percentage.

The current regression suite includes documents across:

10 / 25 / 40 / 50 / 60 / 75 / 100 pages

50-page and 100-page Canvas documents are part of the current verified test range.

100 pages is not a hard package limit. Practical limits still depend on the document, images, browser memory, rendering mode, security settings, and the device being used.

Cancellation

Long-running PDF generation can now be cancelled.

pdf.value?.cancelGeneration()

Cancellation is cooperative and works across the generation pipeline.

The library also tests recovery after cancellation, so a new PDF can be generated after an earlier operation was cancelled.

Some already-running synchronous browser operations cannot always be stopped immediately, but the pipeline checks for cancellation between major stages.

Page-aware progress

Progress reporting now includes more than a simple percentage.

The package can expose:

current progress
current page
total pages
current processing stage

Stages include:

pagination
images
preparing
rendering
watermark
header
footer
metadata
serializing
complete
error

This makes it possible to build UI such as:

Rendering page 18 of 50...

instead of showing an indefinite spinner.

Headers

Headers can contain:

plain text
trusted HTML
optional logos
custom backgrounds and text colors
configurable logo dimensions
selected-page targeting

A header can appear on:

all pages
the first page only
the last page only
every page except the first
explicit page numbers

Selective header targeting also uses page-aware spacing, so header space is reserved only where the header is actually rendered.

Footers

Footers support:

HTML mode
text mode
trusted HTML content
optional logos
configurable logo dimensions
background and text colors
page-number templates

For example:

Page {n} of {total}

Header and footer logos preserve their aspect ratio instead of being stretched into a fixed box.

Static HTML footers are now rendered once and reused across pages instead of being rasterized repeatedly.

In project benchmark fixtures:

HTML footer without logo
7.82s -> 1.43s

HTML footer with logo
11.81s -> 1.29s

Footer-heavy PDF size
~46.7 MB -> ~1.0 MB

These numbers are specific to the benchmark fixtures and should not be treated as universal performance guarantees.

Repeated image optimization

Selectable-text rendering now caches repeated images within a single generation.

If the same image is reused across many pages, the package can avoid repeatedly loading and encoding the same source.

The cache is scoped to one PDF generation and is cleared afterward.

This is especially useful for documents containing repeated logos, icons, product images, or other shared assets.

Resource cleanup

A lot of work also went into cleaning temporary resources earlier.

The generation pipeline now handles cleanup of things such as:

temporary cloned DOM nodes
temporary canvases
encoded image data
per-generation image caches
rendering state

Canvas backing stores are also released when possible after they are no longer needed.

Repeated-generation and isolation tests were added to help detect regressions in cleanup behavior.

Browser responsiveness

Large PDF generation is naturally expensive, especially in Canvas mode.

The pipeline now yields between selected expensive operations so the browser gets opportunities to process UI work while generation is running.

Combined with cancellation and page-aware progress, this makes long-running generation easier to integrate into real applications.

Watermarks

Watermarks can be:

text or image
foreground or background
single or repeated
rotated
positioned
configured with opacity
targeted to selected PDF pages

PDF security

You can optionally generate password-protected PDFs with:

user/open password
owner password
configurable permissions
password construction from multiple password parts

Supported permission controls include:

print
modify
copy
annot-forms

Metadata and compression

PDF metadata can include:

title
author
subject
keywords
creator

jsPDF stream compression can also be enabled when needed.

Clickable links

PDF link annotations are also supported, allowing links in generated documents to remain interactive instead of becoming plain visual text.

Safer filenames

Generated filenames are normalized before download.

This includes handling invalid filename characters, whitespace, reserved Windows names, trailing dots or spaces, and overly long filenames.

Unicode filenames are still preserved.

A note about encrypted raster PDFs

While profiling larger secured documents, I found that encrypted raster PDFs could retain significantly more browser memory than equivalent unencrypted PDFs.

I reproduced the behavior directly with jsPDF outside the main vue3-pdf-export rendering pipeline.

That means a substantial part of this behavior appears to come from the underlying PDF library rather than from the Vue component itself.

I opened an upstream jsPDF issue with the reproduction and benchmark details:

https://github.com/parallax/jsPDF/issues/4017

For large secured documents, selectable-text mode can sometimes be a useful alternative because text-based PDFs are generally much smaller than equivalent rasterized documents.

This is still workload-dependent, so applications generating large encrypted PDFs should test their own representative content.

Testing and performance work

The project now includes automated testing around:

unit behavior
Chromium
Firefox
WebKit
large documents
Canvas rendering
selectable-text rendering
cancellation and recovery
image-heavy documents
repeated images
footer optimization
browser cleanup
security behavior
memory measurements
repeated generation
stress testing

The current unit suite contains:

19 test files
106 tests

There are also dedicated benchmark and Playwright workflows for performance-heavy scenarios.

For heavy PDF tests, I intentionally run browser work sequentially where appropriate so multiple workers do not distort memory measurements.

Why I built a Vue layer instead of replacing the underlying libraries

The goal was never to pretend that html2pdf.js, html2canvas, or jsPDF do not exist.

Those libraries still provide important pieces of the Canvas rendering pipeline.

The goal of vue3-pdf-export is to provide a Vue-oriented layer around PDF generation so common production requirements do not need to be rebuilt for every application.

At the same time, developers can still pass advanced html2pdf.js and jsPDF options when the higher-level API is not enough.

The selectable-text renderer provides another option for cases where real PDF text matters more than exact Canvas-style browser rendering.

Current release

The current release is:

vue-pdf-export v1.0.0

The project has grown significantly since the original release, including:

Canvas and selectable-text rendering modes
incremental page-by-page Canvas generation
large-document regression coverage
cancellation and recovery
current-page / total-page progress
repeated-image caching
footer rendering optimization
earlier DOM and Canvas cleanup
browser responsiveness improvements
PDF security
metadata and compression
clickable links
trusted HTML headers and footers
logo support
watermarks
filename normalization
expanded unit, browser, stress, and performance testing

Try it

🧪 Live Playground
https://vue-pdf-export-playground.vercel.app/

📖 Documentation
https://vue-pdf-export-docs.vercel.app/

📦 npm
https://www.npmjs.com/package/vue-pdf-export

💬 Feature requests & feedback
https://vue3-pdf-export.canny.io/

I’d really appreciate feedback from Vue and Nuxt developers, especially around real-world PDF edge cases, API ergonomics, pagination, large documents, or features you would expect from a Vue PDF library.

If you are building a Vue application that needs client-side PDF generation, I would love to hear about the kinds of documents you are generating and the edge cases you run into.

The project is still evolving, and real-world feedback is one of the most useful inputs for deciding what to improve next. If you find a bug, performance cases, or have an idea for an API improvement, feel free to let me know.

Testing Nuxt apps in the real browser, against a real backend

Wed, 17 Jun 2026 22:17:03 +0000

You just built a Nuxt todo page. It loads from a Nitro route, adds a todo, deletes one, and it works when you click around. Now you want a test that proves it keeps working.

The usual answer is to leave the app, stand up a separate test stack, and rebuild the page in a fake environment with every route mocked. TWD takes the other path: test it where you already are, while you are still building it.

TWD runs your tests inside the Nuxt dev server, in the real browser tab where the app already runs. The same todo page gets tested end to end, against your real backend. No route mocks, no separate e2e stack, no jsdom.

Here is the full setup.

Setup

npm install --save-dev twd-js
npx twd-js init public --save

Add the Vite plugin in nuxt.config.ts:

import { twd } from 'twd-js/vite-plugin'

export default defineNuxtConfig({
  vite: {
    plugins: [
      twd({ testFilePattern: '/**/*.twd.test.{ts,tsx}' }),
    ],
  },
})

Two Nuxt-specific bits to wire up, both one-time.

Nuxt does not serve a Vite index.html. Nitro renders the HTML, so the plugin cannot auto-inject its sidebar script. Point your app at the virtual module yourself, dev-only, in app.vue:

<script setup lang="ts">
if (import.meta.dev) {
  useHead({
    script: [{ src: '/_nuxt/@id/virtual:twd/init', type: 'module' }],
  })
}
</script>

<template>
  <div>
    <NuxtPage />
  </div>
</template>

Note the /_nuxt/ prefix, that is Nuxt's Vite base. The import.meta.dev guard keeps the tag out of production.

2. Reload the browser when a test file changes

On Nuxt 4 with Vite 7, editing a .twd.test file does not reload the browser on its own. This small plugin fixes it: it watches your test files and triggers a reload when one changes.

// npm install --save-dev chokidar
import chokidar from 'chokidar'
import type { Plugin } from 'vite'

function twdTestHmr(): Plugin {
  const isTestFile = (file: string) => /\.twd\.test\.tsx?$/.test(file)
  return {
    name: 'twd-test-hmr',
    apply: 'serve',
    configureServer(server) {
      // Under Nuxt, Vite's config.root is the app/ srcDir, where the tests live.
      const watcher = chokidar.watch(server.config.root, {
        ignored: (path) => /node_modules|\.nuxt|\.output|\.git/.test(path),
        ignoreInitial: true,
      })
      const reload = (file: string) => {
        if (!isTestFile(file)) return
        // Drop the cached module so the reload serves fresh code.
        const graph = server.environments?.client?.moduleGraph ?? server.moduleGraph
        for (const mod of graph.getModulesByFile(file) ?? []) {
          graph.invalidateModule(mod)
        }
        server.ws.send({ type: 'full-reload', path: '*' })
      }
      watcher.on('change', reload).on('add', reload).on('unlink', reload)
      server.httpServer?.once('close', () => void watcher.close())
    },
  }
}

Add twdTestHmr() to the plugins array next to twd(). Edit a test, the browser reloads.

Run npm run dev. Sidebar on the left, your app on the right.

Testing against the real backend

You do not mock routes. The tests hit your dev server and your database for real. The only thing you need is a clean starting point for each test.

A dev-only endpoint gives you that. It resets the database to a seeded baseline, guarded so it never exists in production:

// server/api/__test/reset.post.ts
export default defineEventHandler(() => {
  if (!import.meta.dev) {
    throw createError({ statusCode: 404, statusMessage: 'Not found' })
  }
  resetDb()
  return { ok: true, todos: listTodos() }
})

resetDb() deletes every row, resets the id sequence so seeded ids are deterministic, and re-seeds. The import.meta.dev guard means the route returns 404 in a production build.

Call it before each test, then drive the real UI:

import { twd, userEvent, screenDom } from 'twd-js'
import { describe, it, beforeEach } from 'twd-js/runner'

describe('Todos (real SQLite backend)', () => {
  beforeEach(async () => {
    // Reset the database to its seeded state. No route mocking.
    await fetch('/api/__test/reset', { method: 'POST' })
  })

  it('creates a todo end to end', async () => {
    await twd.visit('/todos')
    await userEvent.type(screenDom.getByTestId('todo-input'), 'Buy milk')
    await userEvent.click(screenDom.getByTestId('todo-add'))

    twd.should(await screenDom.findByText('Buy milk'), 'be.visible')
  })
})

No mock rules. The POST persists to the database, the list refreshes, and the assertion runs against the real rendered DOM. Delete a row and assert it is gone, same shape. When a test fails, it failed against the real backend, not against a mock you forgot to update.

Try it

Sample repo: BRIKEV/twd-nuxt-example. Nuxt 4, a SQLite-backed todo list, the HMR plugin, the dev-only reset endpoint, and tests that run against the real backend.
Docs: twd.dev

npm install --save-dev twd-js
npx twd-js init public --save

Add the plugin to nuxt.config.ts, drop the dev-only script into app.vue, add the HMR plugin, write your first .twd.test.ts. The sidebar opens itself.

✨ A New Stack — Introducing Redis Nuxt Blog: A Sci-Fi Blog Boilerplate from a Galaxy Not So Far Away

Thu, 23 Apr 2026 16:49:31 +0000

“A long time ago, in a server rack far, far away, a lone developer sought a faster way to publish their thoughts across the galaxy…”

If you’re a developer roaming the cosmic void in search of the perfect blogging platform — one fast enough to outrun hyperspace lag, simple enough to configure from a single holocron file, and powered by the mighty Force of Redis — your quest ends here.

Welcome to Redis Nuxt Blog, a futuristic, high-performance boilerplate forged with Nuxt 3, Redis Stack, and a containerized fleet of Docker Star Destroyers.
Inspired by the legendary Salvatore “antirez” Sanfilippo, creator of Redis and intergalactic craftsman of absurdly fast data structures, this project aims to honor that sci-fi spirit — equal parts elegance, speed, and space-wizardry.

Grab your lightsabers, devs. We’re jumping to lightspeed. ⚡

Why Another Blog Boilerplate?

Because most blog starters are like broken droids — sluggish, uncustomizable, and likely to beep something rude at you when you change a font.

Redis Nuxt Blog is built for developers who want:

A fast, SSR-friendly, SEO-happy front-end
A database engine so quick it would embarrass a pod-racer
A deeply configurable UI without fiddling with 27 separate config files
A ready-to-launch Docker setup
A CLI so efficient it feels like talking to R2-D2 (but without the panic screams)
A theming system powered by Tailwind CSS, customizable from one file
Markdown-powered post content
Dynamic excerpts and content width control

✨ Core Features (Translated from Wookiee)

Nuxt.js 3 Frontend

Modern. Fast. SSR-powered.
Perfect for blogs, portals, and broadcasting your galactic manifestos.

⚡ Redis Stack as the Primary Database

Forget SQL. Forget slow disks.
We harness the Quantum Hyperdrive (a.k.a RedisJSON + Redis Sorted Sets) to store posts with blazing speed.

Salvatore Sanfilippo didn’t intend Redis to be a sci-fi artifact… but let’s be honest, it might as well have been forged from midichlorians.

One Config File to Rule Them All (Now With Full Tailwind Integration)

Every visual setting — fonts, weights, palette, spacing, even content width — comes from:

config/blog.config.ts

This single file now controls:

Typography per heading level
Full Tailwind color palette generation
Global content max-width
Header title & tagline
Layout constraints

Balance to the styling Force, at last.

✂️ Post Excerpts (New!)

Enable post previews on the homepage with:

postExcerpt.enabled
postExcerpt.maxLength

Perfect for teasing your readers like a Holonet trailer.

Navigate between posts like browsing encrypted Jedi archives.

Markdown Support

Posts are fully Markdown-powered — headings, lists, code blocks, even multi-line input via CLI.

Write your galactic knowledge in pure Markdown. No HTML acrobatics needed.

Dockerized Everything

Spin up Nuxt + Redis with one command:

docker compose up -d --build

Your dev environment becomes as consistent as Stormtrooper aim (but… good).

Content CLI (Upgraded!)

Create, list, delete posts with simple commands:

npm run new-post npm run post:list npm run post:delete

The CLI now supports:

Multi-line Markdown input
Automatically generated slugs
Default author fallback

You are now the administrator of your own Holocron Library.

️ Tech Stack: What Our Starship Is Made Of

Nuxt 3 — the elegant lightsaber
Redis Stack w/ RedisJSON — the hyperdrive core
Tailwind CSS — the robe of a modern Jedi developer
Google Fonts module — for typographic wizardry
Docker Compose — the Imperial Fleet
TypeScript + tsx runtime — because even smugglers need types

️ The Holocron of Configuration (Updated!)

Everything — fonts, colors, layout, excerpts, pagination — lives in:

config/blog.config.ts

New additions include:

headerTitle
headerTagline
Dynamic Tailwind theme generation
contentMaxWidth
Post excerpts config

Want your blog to have an imperial blue palette?
Done.

Want H1 in Englebert and H2 in Roboto Slab?
Absolutely.

Want your content width to feel like the inside of a Star Destroyer corridor?
Just set a new max-width.

API Endpoints (For the Droids Among Us)

Endpoint	Method	Description
`/api/posts`	GET	Retrieve posts. Supports `?page=N`
`/api/posts/:slug`	GET	Fetch single post + neighbors
`/api/tags`	GET	Retrieve all tags

Perfect for custom frontends, mobile apps, or your own droid companion.

Why Developers Love This

Because simplicity + power = developer bliss.

Because Redis is a piece of sci-fi technology disguised as a database.

Because Nuxt 3 is smooth as sliding through hyperspace.

Because Tailwind lets you customize everything without rewriting CSS.

Because Markdown posts feel like writing Jedi scrolls.

And because every post stored in Redis Sorted Sets is basically organized by the Force.

Author & Origin Story

Built by Luca Visciola — drummer, developer, and happy dad.

Inspired by Salvatore “antirez” Sanfilippo, whose creation Redis is widely believed to be running not on silicon… but on compressed fragments of a neutron star.

Final Transmission

If you're searching for a fast, flexible, sci-fi-friendly blog engine that handles posts faster than the Millennium Falcon outruns TIE Fighters, this boilerplate may be the one you’re looking for.

Clone it.
Customize it.
Seed it.
Deploy it.

GitHub Repository:
https://github.com/melasistema/redis-blog

And may the Force of Redis be with you. ❤️‍

Coder Legion - Recent posts tagged nuxt

I Kept Rebuilding PDF Features in Vue 3, So I Built vue-pdf-export

What it supports

Installation

Basic usage

Canvas or selectable text

Programmatic output

Nuxt support

Pagination

Large-document rendering

Cancellation

Page-aware progress

Headers

Footers

Footer performance improvements

Repeated image optimization

Resource cleanup

Browser responsiveness

Watermarks

PDF security

Metadata and compression

Clickable links

Safer filenames

A note about encrypted raster PDFs

Testing and performance work

Why I built a Vue layer instead of replacing the underlying libraries

Current release

Try it

Testing Nuxt apps in the real browser, against a real backend

Setup

1. Inject the sidebar in app.vue

2. Reload the browser when a test file changes

Testing against the real backend

Try it

✨ A New Stack — Introducing Redis Nuxt Blog: A Sci-Fi Blog Boilerplate from a Galaxy Not So Far Away

Why Another Blog Boilerplate?

✨ Core Features (Translated from Wookiee)

Nuxt.js 3 Frontend

⚡ Redis Stack as the Primary Database

One Config File to Rule Them All (Now With Full Tailwind Integration)

✂️ Post Excerpts (New!)

↔️ Post Navigation

Markdown Support

Dockerized Everything

Content CLI (Upgraded!)

️ Tech Stack: What Our Starship Is Made Of

️ The Holocron of Configuration (Updated!)

API Endpoints (For the Droids Among Us)

Why Developers Love This

Author & Origin Story

Final Transmission