feat!: plausible script updates

[harlan-zw]

🔗 Linked issue

❓ Type of change

• 📖 Documentation (updates to the documentation or readme)
• 🐞 Bug fix (a non-breaking change that fixes an issue)
• 👌 Enhancement (improving an existing functionality)
• ✨ New feature (a non-breaking change that adds functionality)
• 🧹 Chore (updates to the build process or auxiliary tools and libraries)
• ⚠️ Breaking change (fix or feature that would cause existing functionality to change)

📚 Description

⚠️ Not breaking but please test your plausible integration after updating.

Plausible introduced a new script format in October 2025 with unique per-site script IDs and plausible.init() for configuration instead of script extensions.

1. Unique Script IDs: Each site now gets a unique script ID (found in Site Installation settings)
2. No more extensions: Configuration is done via plausible.init() options instead of script extensions
3. Simplified setup: Custom events, revenue tracking, and form submissions are now automatically available

We support the legacy usage of the script however it is now deprecated and users should migrate.

Migration Guide

Old format (domain + extensions):

useScriptPlausibleAnalytics({
  domain: 'example.com',
  extension: ['hash', 'outbound-links']
})

New format (scriptId + init options):

useScriptPlausibleAnalytics({
  scriptId: 'YOUR_SCRIPT_ID', // Get from Plausible dashboard
  hashBasedRouting: true,
  // outbound-links is now enabled by default
})

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Preview	Comments	Updated (UTC)
scripts-docs	Error			Oct 14, 2025 4:47am
scripts-playground	Ready	Preview	Comment	Oct 14, 2025 4:47am

[pkg-pr-new]

Open in StackBlitz

npm i https://pkg.pr.new/nuxt/scripts/@nuxt/scripts@534

commit: 4fd4a4b

[huang-julien]

How about having two separate usePlausibleAnalytics composable ?

[harlan-zw]

I thought about this, but I don't want to have to manage a bunch of arbitrary version postfixes on composable name, it complicates docs, end user DX and testing.

I'd imagine the original way of embedding the script will work in perpetuity, so if the end user doesn't migrate off this, it's not a big deal.

Thanks for the review!