DEV Community: Saurabh Choudhary

Building Better PDF Workflows in Vue 3 with vue-pdf-export

Saurabh Choudhary — Sat, 12 Sep 2026 16:27:39 +0000

Hey Vue developers 👋

I’ve been working on vue-pdf-export, a Vue 3 + TypeScript package for generating PDFs directly in the browser.

I originally created it because I kept rebuilding the same PDF features across different Vue projects - pagination, preview, printing, headers, footers, progress handling, and long-document support.

Some of the things it supports today:

Canvas and selectable/searchable PDF text
Automatic and manual pagination
Preview, download, and browser print
Headers and footers
Watermarks
Password protection and PDF permissions
Clickable links
Progress reporting and cancellation
Blob, ArrayBuffer, and Base64 output
Export-only styling and data-pdf-ignore
Nuxt 3 and Nuxt 4 SSR-safe imports

Install

npm install vue-pdf-export

Small example

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

const pdfRef = ref<InstanceType<typeof Html2Pdf> | null>(null)
</script>

<template>
  <button @click="pdfRef?.generatePdf()">
    Generate PDF
  </button>

  <Html2Pdf ref="pdfRef" filename="report.pdf">
    <template #pdf-content>
      <h1>Hello from Vue</h1>
      <p>This content will be exported to PDF.</p>
    </template>
  </Html2Pdf>
</template>

Try it

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

I’d really like feedback from Vue developers who have worked with PDFs in production - especially around pagination, large documents, selectable text, and API ergonomics.

I built vue-pdf-export - a Vue 3 PDF Export library for real-world browser apps

Saurabh Choudhary — Sat, 12 Sep 2026 11:24:34 +0000

Hey everyone 👋

I recently released vue-pdf-export, a 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.

Install

npm install vue-pdf-export

Basic usage

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

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

<template>
  <button @click="pdf?.generatePdf()">
    Generate PDF
  </button>

  <Html2Pdf
    ref="pdf"
    filename="example.pdf"
  >
    <template #pdf-content>
      <h1>Hello from Vue</h1>
      <p>This content will be exported to PDF.</p>
    </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.

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.

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.

The project is still evolving, and real-world feedback is one of the most useful inputs for deciding what to improve next.

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

Saurabh Choudhary — Thu, 03 Sep 2026 23:41:35 +0000

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

I recently published vue-pdf-export, a Vue + TypeScript package for generating PDFs directly from HTML in browser applications.

Vue + TypeScript browser PDF generation with Canvas and selectable-text
rendering, pagination, preview, large-document support, cancellation,
progress reporting, headers, footers, watermarks, security, metadata,
compression, links, and more.

Why I built it

Before publishing vue-pdf-export, I had already worked on PDF generation in different projects, including Google projects, CRM applications, and other Vue-based applications.

I tried different HTML-to-PDF approaches and existing libraries, but in real projects I often ended up building my own custom Vue PDF component around them to handle the specific requirements I needed.

Whenever a new project needed PDF generation, I found myself solving many of the same problems again:

pagination
page breaks
preview
download
printing
headers and footers
image handling
different PDF options
loading states
long-running generation
browser memory usage
security and metadata

This time, instead of creating another project-specific component, I decided to build a cleaner and more complete solution that I could reuse across Vue projects.

That became vue-pdf-export.

The main reason was simple: I did not want to keep rebuilding the same PDF functionality again and again.

And if it can also save time for other Vue developers who need similar PDF features, even better.

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>

Two rendering modes

One of the biggest additions is support for two different PDF rendering strategies.

Canvas mode

Canvas mode is the traditional HTML-to-PDF path and is best when browser CSS fidelity is the main priority.

It uses the familiar html2pdf.js / html2canvas / jsPDF pipeline underneath.

<Html2Pdf render-mode="canvas">

This remains the package default for backward compatibility.

Selectable text mode

Text mode generates real PDF text instead of rasterizing the body into a canvas.

<Html2Pdf render-mode="text">

The resulting text can be:

selected
searched
copied

This can be especially useful for reports, invoices, documentation, and other text-heavy PDFs.

Because this renderer does not behave exactly like a browser layout engine, some advanced CSS may render differently compared with Canvas mode.

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

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.

Footer performance improvements

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

📄 Explore the documentation : vue-pdf-export-docs.vercel.app

🌐 Live Playground

Explore the features and generate PDFs directly in the browser:

vue3-pdf-export-playground

📦 npm Package

Install and use the package in your Vue 3 project:

npmjs.com/package/vue-pdf-export

The package is available for Vue 3 applications and continues to evolve around real-world PDF generation requirements.

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.

If you find a bug, performance cases, or have an idea for an API improvement, feel free to let me know.

Built Log Stripper: A VS Code Extension to Remove Debug Logs Across 23+ Languages

Saurabh Choudhary — Wed, 03 Jun 2026 07:36:42 +0000

Every developer has a version of this story.

You're about to open a pull request. The code works. The tests pass. Everything looks good.

Then you do one final scan and find this:

console.log("HERE");
console.log("user:", user);
console.log("final:", result);

And then, before the PR:

Search → Delete. Search → Delete. Search → Delete.

I got tired of it. So I built a tool to automate it.

What is Log Stripper?

Log Stripper is a VS Code extension that removes debug, log, and print statements from 23+ programming languages - with a preview so you always see what will be deleted before anything changes.

🔗 VS Code Marketplace
🔗 GitHub

The Features

🔍 Preview mode - Ctrl+Shift+D

Shows every line that will be removed. You confirm. Only then does anything change.

🎨 Highlight mode - Ctrl+Shift+H

Marks debug lines in red. No file modification. Review first, strip later.

🌍 23+ languages

JS, TS, Python, Java, Go, Rust, C#, Swift, Kotlin, Dart, Ruby, PHP, C, C++, Shell, Lua, Scala, Elixir, Haskell, R, Vue, Svelte, JSX/TSX

🏢 Workspace cleanup

Strip debug statements from an entire project in one command.

Why not just use grep/sed?

You could. But:

No preview
No multiline support
No VS Code integration
No safety rules
Works differently on Windows vs Mac vs Linux Log Stripper handles all of this inside VS Code with a consistent UX.

The Interesting Technical Part: Multiline Removal

Removing a single-line console.log("x") is trivial. The interesting case is:

console.log(
  "user:",
  JSON.stringify(user, null, 2),
  "role:",
  user.role
);

To remove this correctly, you need to:

Find the opening (
Track paren depth across lines
Handle parens inside strings (don't count those)
Find the exact closing ) and optional ;
Remove the entire block without touching surrounding code Here's the core of skipParenBlock:

function skipParenBlock(lines: string[], startLine: number) {
  const openIdx = lines[startLine].indexOf("(");
  let bal = 1, li = startLine, ci = openIdx + 1;
  let inStr: string | null = null;

  while (li < lines.length) {
    const s = lines[li];
    while (ci < s.length) {
      const ch = s[ci];
      if (inStr) {
        if (ch === "\\") { ci += 2; continue; }
        if (ch === inStr) inStr = null;
      } else if (ch === '"' || ch === "'" || ch === "`") {
        inStr = ch;
      } else if (ch === "(") {
        bal++;
      } else if (ch === ")") {
        bal--;
        if (bal === 0) {
          ci++;
          if (s[ci] === ";") ci++;
          return { endLine: li, endCol: ci };
        }
      }
      ci++;
    }
    li++; ci = 0;
  }
}

Architecture Decision

I separated the core logic from the VS Code layer:

src/
├── extension.ts   ← VS Code commands, UI, workspace
└── stripper.ts    ← Pure logic, zero VS Code deps

Why? Because stripper.ts can be tested without launching a VS Code host:

node --test out-test/test/stripper.test.js

151 tests. Fast. No mocking needed.

Safety Rules

The extension will never remove:

// console.log("commented") ← comment line, always kept
return console.log(x);       ← inline code, always kept
const x = doThing() || console.log("fallback"); ← inline, kept

Only whole-statement debug calls that are the entire line (after indentation) are removed.

The Languages Covered

Language	Examples
JS/TS	`console.log`, `debugger`
Python	`print()`, `logging.debug()`, `breakpoint()`
Java	`System.out.println`, `logger.debug()`
Go	`fmt.Println`, `log.Fatal`
Rust	`println!`, `dbg!`, `eprintln!`
C#	`Console.WriteLine`, `Debug.Write`
Swift	`print()`, `NSLog()`
Ruby	`puts`, `binding.pry`
PHP	`var_dump()`, `dd()`
Shell	`echo`, `printf`
...13 more	-

Try It

# Install from Marketplace
code --install-extension saurabhchoudhary.log-stripper

Or search "Log Stripper" in the VS Code extensions panel.

Open a file with debug statements → Ctrl+Shift+D → see the preview → confirm.

Toggle Debug Highlights | Highlight/unhighlight debug lines

Preview & Strip Current File | Shows preview, then strips on confirm

Command Palette | Strip Entire Workspace | Clean whole project

Right-click → menu | Strip Current File | Strip without preview

Editor toolbar icons (eye / eye-closed / trash)

Built this because I couldn't find a tool that did all of this properly. Turned out to be one of the most satisfying weekend projects I've done.

If you try it, I'd love feedback in the comments or as a GitHub issue. 🙌

By Saurabh Choudhary - Software Engineer

Introduction

Every developer has a version of this story.

You're about to open a pull request. The code works. The tests pass. You're ready. Then you do one last scroll through the file and see it:

console.log("HERE");
console.log("user data:", JSON.stringify(userData));
console.log("response", res);

Three debug logs you forgot to remove. You delete them, re-run the linter, and open the PR.

Two weeks later, someone reports that production logs are noisy with debug output. A developer on your team had left a logger.debug() in a hot path. Nobody caught it in review.

This isn't a rare occurrence. It's a pattern that plays out in every team, on every codebase, in every programming language.

I've experienced it across JavaScript, TypeScript, PHP, Go, Python, Vue.js, NestJS, Laravel, and Angular projects. Different languages, different ecosystems - same repetitive problem.

Eventually I stopped accepting it as "just part of the workflow" and decided to build a proper solution.

That solution is Log Stripper - a VS Code extension that removes debug, log, and print statements from 23+ programming languages with a safety-first, preview-driven approach.

The Problem

The problem has two dimensions that are easy to underestimate.

First: it's repetitive. Before every commit, before every PR, before every release, developers go through the same manual process of searching for and deleting debug statements. On large codebases with dozens of files touched in a single feature branch, this becomes genuinely time-consuming.

Second: it's error-prone. Humans miss things. A console.log inside a nested callback, a print() inside a conditional branch, a System.out.println buried in a Java service - these are easy to overlook when scanning files manually. And when they slip through, they end up in production.

There's also a subtler issue: developers working under time pressure will rush the cleanup. The more pressure, the more likely something gets missed.

This is exactly the kind of task that should be automated. It is deterministic, repetitive, and rule-based. A computer should do it.

Why Existing Workflows Were Frustrating

Before building Log Stripper, I searched for existing solutions.

I found a few extensions that handled console.log removal for JavaScript. Some worked well for that specific case. But they had significant limitations:

Language coverage was narrow. Most extensions focused exclusively on JavaScript. If you wrote Python, Go, Java, or Rust, you were on your own.

No preview mode. Several extensions deleted statements immediately without showing you what would be removed. That's unsafe. A developer who accidentally removes a legitimate logger call in production code will stop trusting the tool immediately.

No highlight mode. Sometimes I want to see the debug statements in a file without removing anything yet. I want to review them, understand them, decide manually. None of the tools I found offered non-destructive inspection.

No workspace cleanup. File-by-file cleanup doesn't scale. Before a major release, I want to scan an entire project and clean everything in one pass.

Unreliable multiline handling. A console.log that spans multiple lines is common:

console.log(
  "processing user:",
  JSON.stringify(user, null, 2)
);

Many tools would only remove the first line and leave the rest, creating syntax errors.

Why I Built Log Stripper

The decision to build rather than adapt came down to one realization: the problem deserved a proper solution, not a workaround.

I wanted an extension that:

Worked across every major language I use day-to-day
Showed a preview before making any changes
Could highlight debug lines without modifying files
Could clean an entire workspace safely
Was smart enough to never break code it shouldn't touch
Was backed by automated tests None of those requirements are unreasonable. Together, they're the minimum bar for a tool I'd actually trust.

The weekend I started building it, I intended it to be a one-day project. It grew into something more substantial as I realized the edge cases, the safety requirements, and the value of doing it properly.

Architecture

The most important architectural decision I made was separating the core logic from the VS Code integration layer.

The repository has two source files:

src/
├── extension.ts    ← VS Code commands, UI, workspace operations
└── stripper.ts     ← Core strip logic (zero VS Code dependencies)

stripper.ts has no awareness of VS Code. It takes a string of text and a language ID, and returns a new string with debug statements removed plus metadata about what was changed. That's it.

This separation has two major benefits:

Testability. I can test the core logic without launching a VS Code Extension Development Host. The 151 automated tests run with a plain node --test command. Fast, simple, reliable.

Maintainability. If VS Code changes its API, or if I want to port the logic to a CLI tool or a git pre-commit hook, the core logic doesn't need to change.

The VS Code layer handles everything user-facing: commands, keybindings, settings, decorations, progress notifications, and workspace file scanning.

Multi-Language Support

Supporting 23 languages sounds ambitious. The implementation is actually straightforward once you have the right architecture.

Each language is a key in the LANGUAGE_PATTERNS object, and its value is an array of regular expressions:

const LANGUAGE_PATTERNS: Record<string, RegExp[]> = {
  javascript: [
    /^(\s*)console\.(log|debug|info|warn|error|trace|...)\s*\(/,
    /^(\s*)debugger\s*;?$/,
  ],
  python: [
    /^(\s*)print\s*\(/,
    /^(\s*)logging\.(debug|info|warning|error|critical)\s*\(/,
    /^(\s*)breakpoint\s*\(\s*\)/,
  ],
  // ... 21 more languages
};

Language aliases handle cases where VS Code's language ID differs from the pattern group:

const LANG_ALIASES: Record<string, string> = {
  svelte: "javascript",
  "vue-html": "vue",
  typescriptreact: "typescript",
};

When the extension receives a file, it looks up the language ID, finds the pattern list, and applies each pattern against every line. If no patterns are found for a language, the file is returned unchanged.

Adding a new language is a matter of adding one entry to LANGUAGE_PATTERNS and a set of test cases to stripper.test.ts. The infrastructure handles the rest.

Preview Mode

The preview mode was the feature I was most deliberate about designing.

When a developer triggers "Preview & Strip" with Ctrl+Shift+D, the extension:

Runs the stripping logic internally (without modifying the file)
Collects the list of lines that would be removed
Shows a modal dialog listing those lines with their line numbers
Waits for explicit confirmation before making any changes This turns a potentially destructive operation into a fully transparent, opt-in action. The developer sees exactly what will happen and retains full control.

The modal includes the first 20 matching lines and appends "...and N more" if there are additional matches. This keeps the dialog readable on files with heavy debug coverage.

If the developer cancels, nothing changes. Not a single character in the file is modified.

Highlight Mode

Highlight mode solves a different need: I want to see the debug statements but I'm not ready to remove them yet.

When the developer presses Ctrl+Shift+H, the extension:

Finds all lines matching debug patterns using findDebugLineIndices()
Applies a VS Code text decoration that highlights those lines in red
Adds an inline annotation "← debug" at the end of each line The file is not modified. This is purely a visual overlay.

Pressing Ctrl+Shift+H again (or clicking the eye-closed icon in the toolbar) removes the highlights.

The highlight controller also handles three lifecycle events automatically:

When you strip the file, highlights are cleared (no red lines on lines that no longer exist)
When you edit the file and refreshHighlightsOnEdit is enabled, highlights recompute after a 120ms debounce

- When you switch tabs and `clearHighlightsOnTabChange` is enabled, highlights are cleared automatically

Workspace Cleanup

The workspace strip command scans every file in the project matching the supported language extensions and strips debug statements from each one.

The implementation uses VS Code's workspace.findFiles() API with exclusion patterns to skip node_modules, dist, .git, vendor, build, and out by default. All exclusion patterns are configurable in settings.

The operation runs with a progress notification showing the current file being processed and a cancellation option. After completion, a summary shows how many statements were removed across how many files.

Because this modifies files on disk, the documentation explicitly recommends using version control. A git diff after the workspace strip is always informative.

Safety Design

Safety was a first-class concern throughout the design.

The extension enforces several rules to avoid breaking code it shouldn't touch:

Rule 1: Whole-line only. A debug call is only removed if it is the entire statement on the line (after indentation). This prevents removal of:

return console.log(x);         // kept - inline with return
const result = doWork() || console.log("fallback");  // kept - chained

Rule 2: Comments are never touched. Any line where the first non-whitespace characters form a comment prefix (//, #, --, /*, *) is skipped entirely.

Rule 3: Multiline paren balancing. When a debug call spans multiple lines, the extension tracks open and close parentheses (accounting for parens inside strings) to identify the exact end of the statement. The closing ) and optional ; are consumed, and any remaining code on that final line is preserved.

Rule 4: No modification on cancel. Preview mode never touches the file unless the user explicitly confirms. The stripping logic runs on an in-memory copy of the text, and the result is only written back if the user says yes.

Testing Strategy

I wanted the extension to be trustworthy. That required a proper test suite.

The tests live in test/stripper.test.ts and use Node's built-in test runner - no Jest, no Mocha, no additional dependencies. The test command is:

tsc -p tsconfig.test.json && node --test out-test/test/stripper.test.js

The 151 test cases cover:

Every language in LANGUAGE_PATTERNS
Simple single-line removal
Multiline call removal with paren balancing
Comment preservation
Inline code preservation
Real-world code samples (NestJS controllers, Python classes, Go functions)
Language aliases (Vue, Svelte, JSX, TSX)
Unknown languages (should be a no-op)
The findDebugLineIndices() function (used by highlight mode) Each test specifies the input code, the expected output, and the expected removal count. Any test that would cause the extension to modify code it shouldn't - or fail to modify code it should - is a failing test.

Writing tests before polishing features was the right decision. It caught several edge cases during development and gave me confidence when refactoring the paren-balancing logic.

Publishing to the VS Code Marketplace

The Marketplace publishing process is simpler than I expected.

The key steps:

Create a publisher account at marketplace.visualstudio.com
Generate a Personal Access Token from Azure DevOps with Marketplace → Manage scope
Install @vscode/vsce globally: npm install -g @vscode/vsce
Run vsce package to create the .vsix file
Run vsce publish --pat TOKEN or upload the .vsix manually via the publisher portal The .vscodeignore file controls what goes into the package. I excluded src/, test/, and node_modules/ - only the compiled out/ directory ships. This keeps the extension lightweight.

One thing I'd emphasize: set the repository.url in package.json before publishing. It shows up prominently on the Marketplace listing and signals to users that the extension is open source and maintainable.

Lessons Learned

Separate your core logic from your integration layer. This applies far beyond VS Code extensions. Any time you can isolate the testable business logic from the framework or platform code, do it. It makes everything easier.

Safety features build trust. The preview mode and the "never remove inline code" rule weren't technically necessary for the extension to work. But they're what make a developer comfortable trusting the tool with real production code.

Test the edge cases first. Multiline calls, strings containing parens, empty files, unsupported languages - these were the cases most likely to cause silent failures. Writing tests for them before the happy path forced me to build robust logic from the start.

Ship before it's perfect. The first version didn't have highlight mode. The workspace strip was added later. Shipping v1 with the core feature - preview and strip - got real feedback faster than spending another two weeks on features users might not need.

Small tools have real value. This isn't a SaaS platform. It's not an AI product. It's a focused tool that does one thing well. Developer tools like this get used quietly but consistently. That's enough.

Future Improvements

Several improvements are on the roadmap:

Custom pattern rules. Allow developers to define their own patterns to remove. For teams using custom logging frameworks, this would make Log Stripper work with any codebase.

Pre-commit hook integration. A script or CLI wrapper that can run as a git pre-commit hook, catching debug statements before they ever reach a commit.

Team-wide configuration. A .logstripper.json configuration file that defines excluded patterns per project, shareable across a team through version control.

Ignore comments. A // log-stripper-ignore annotation that tells the extension to skip a specific line or block.

More language coverage. Zig, Nim, OCaml, and Erlang are candidates for future additions.

Conclusion

Log Stripper is a small tool. It solves one problem, and it solves it well.

But the process of building it taught me something more valuable than any individual feature: the instinct to look at a repetitive problem and ask "why am I doing this manually?" is one of the most productive instincts an engineer can develop.

We accept small frictions as part of the job. We work around limitations instead of fixing them. We solve the same problem repeatedly instead of automating it once.

Log Stripper exists because I stopped accepting one of those frictions.

If you're reading this and you have something similar - a small repetitive task, an annoying workflow step, a gap in your tooling - build the solution. The process will teach you more than you expect, and the tool will serve you for years.

Try Log Stripper:

VS Code Marketplace: https://marketplace.visualstudio.com/items?itemName=saurabhchoudhary.log-stripper

GitHub: https://github.com/saurabhzaiswal/Log-Stripper-VS-Code

I'm actively improving Log Stripper, so real-world feedback is incredibly valuable.

If Log Stripper helps keep a few forgotten debug statements out of production, then it has already paid for itself.

DEV Community: Saurabh Choudhary

Building Better PDF Workflows in Vue 3 with vue-pdf-export

Install

Small example

Try it

I built vue-pdf-export - a Vue 3 PDF Export library for real-world browser apps

What it supports

Install

Basic usage

Canvas or selectable text

Programmatic output

Nuxt support

Try it

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

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

Why I built it

Installation

Basic usage

Two rendering modes

Canvas mode

Selectable text mode

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

Built Log Stripper: A VS Code Extension to Remove Debug Logs Across 23+ Languages

What is Log Stripper?

The Features

Why not just use grep/sed?

The Interesting Technical Part: Multiline Removal

Architecture Decision

Safety Rules

The Languages Covered

Try It

Introduction

The Problem

Why Existing Workflows Were Frustrating

Why I Built Log Stripper

Architecture

Multi-Language Support

Preview Mode

Highlight Mode

- When you switch tabs and clearHighlightsOnTabChange is enabled, highlights are cleared automatically

Workspace Cleanup

Safety Design

Testing Strategy

Publishing to the VS Code Marketplace

Lessons Learned

Future Improvements

Conclusion

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

- When you switch tabs and `clearHighlightsOnTabChange` is enabled, highlights are cleared automatically