Merge pull request #43 from filipsobol/main

1. **Breaking change**: Create individual export paths for each integration.
2. Add Next.js integration.
3. Add Nuxt integration.
4. Add Astro integration.
5. Add SvelteKit integration.
6. Add the `enabled` option to control whether to run the plugin.
7. Use Rolldown to build the packages.
8. Update dependencies.

.changeset/config.json

@@ -9,9 +9,15 @@
   "updateInternalDependencies": "patch",
   "ignore": [
     "html-report",
+    "playground-astro",
     "playground-esbuild",
+    "playground-nextjs",
+    "playground-nuxt",
+    "playground-parcel",
     "playground-rollup",
+    "playground-rolldown",
     "playground-rspack",
+    "playground-sveltekit",
     "playground-vite",
     "playground-webpack"
   ]

.changeset/eleven-tomatoes-sniff.md

@@ -0,0 +1,5 @@
+---
+"sonda": patch
+---
+
+Update dependencies

.changeset/fresh-knives-turn.md

@@ -0,0 +1,5 @@
+---
+"sonda": minor
+---
+
+Add Nuxt integration

.changeset/ninety-berries-vanish.md

@@ -0,0 +1,5 @@
+---
+"sonda": minor
+---
+
+Add Astro integration

.changeset/odd-balloons-compare.md

@@ -0,0 +1,5 @@
+---
+"sonda": major
+---
+
+Create an individual export path for each integration

.changeset/tricky-llamas-roll.md

@@ -0,0 +1,5 @@
+---
+"sonda": minor
+---
+
+Add Next.js integration

.changeset/violet-chairs-juggle.md

@@ -0,0 +1,5 @@
+---
+"sonda": minor
+---
+
+Add the `enabled` option to control whether to run the plugin

.github/workflows/main.yml

@@ -10,11 +10,9 @@ jobs:
     steps:
       - name: Checkout
         uses: actions/checkout@v4
-
-      - name: Install pnpm
-        uses: pnpm/action-setup@v4
-        with:
-          version: 9
+
+      - name: Enable corepack
+        run: corepack enable
 
       - name: Install Node.js
         uses: actions/setup-node@v4
@@ -32,4 +30,6 @@ jobs:
         run: pnpm run test
 
       - name: Release preview
+        # Only run on pull requests
+        if: github.event_name == 'pull_request'
         run: pnpx pkg-pr-new publish --compact --comment=update './packages/sonda' './packages/unplugin-sourcemaps'

.github/workflows/publish.yml

@@ -3,7 +3,7 @@ name: Publish packages
 on:
   push:
     branches:
-      - main
+      - release
 
 concurrency: ${{ github.workflow }}-${{ github.ref }}
 
@@ -22,11 +22,9 @@ jobs:
     steps:
       - name: Checkout
         uses: actions/checkout@v4
-
-      - name: Install pnpm
-        uses: pnpm/action-setup@v4
-        with:
-          version: 9
+
+      - name: Enable corepack
+        run: corepack enable
 
       - name: Install Node.js
         uses: actions/setup-node@v4

.gitignore

@@ -12,5 +12,6 @@ package-lock.json
 docs/.vitepress/dist
 docs/.vitepress/cache
 
-sonda-report.*
+sonda-report*
 *.backup
+.parcel-cache

docs/.vitepress/config.ts

@@ -14,7 +14,7 @@ export default defineConfig({
     logo: '/sonda.jpg',
 
     nav: [
-      { text: 'Guide', link: '/introduction' },
+      { text: 'Guide', link: '/getting-started' },
       { text: 'Demo', link: '/demo.html', target: '_blank' },
     ],
 
@@ -23,9 +23,35 @@ export default defineConfig({
         text: 'Getting started',
         items: [
           { text: 'Introduction', link: '/introduction' },
+          { text: 'Getting started', link: '/getting-started' },
           { text: 'Configuration', link: '/configuration' },
         ]
       },
+      {
+        text: 'Integrations',
+        items: [
+          {
+            text: 'Bundlers',
+            items: [
+              { text: 'Vite', link: '/bundlers/vite' },
+              { text: 'Rollup', link: '/bundlers/rollup' },
+              // { text: 'Rolldown', link: '/bundlers/rolldown' },
+              { text: 'esbuild', link: '/bundlers/esbuild' },
+              { text: 'webpack', link: '/bundlers/webpack' },
+              { text: 'Rspack', link: '/bundlers/rspack' },
+            ]
+          },
+          {
+            text: 'Frameworks',
+            items: [
+              { text: 'Next.js', link: '/frameworks/nextjs' },
+              { text: 'Nuxt', link: '/frameworks/nuxt' },
+              { text: 'Astro', link: '/frameworks/astro' },
+              { text: 'SvelteKit', link: '/frameworks/sveltekit' },
+            ]
+          }
+        ]
+      },
       {
         text: 'Features',
         items: [

docs/blog/what-makes-sonda-accurate.md

@@ -1,53 +1,57 @@
 # What makes Sonda accurate?
 
 ::: tip TL;DR
-It is the source maps.
+It's the source maps.
 :::
 
-Would you use a measurement tool if you knew it would give you inaccurate results? Of course not. You want to know that the information you have are reliable and accurate.
+Would you use a measurement tool if you knew it provided inaccurate results? Of course not. You need reliable and accurate information.
 
-That is why one of the most important features of Sonda is its accuracy. But what makes Sonda accurate? The answer is fairly simple, but first let's take a look at why we often got inaccurate results with other bundle analyzers in the past.
+That’s why one of the key features of Sonda is its accuracy. But what makes Sonda accurate? The answer is straightforward, but first, let's examine why other bundle analyzers often provided inaccurate results in the past.
 
 ## Why are (some) other bundle analyzers inaccurate?
 
-Depending on the bundle analyzers you used, you may have seen results that were way off. Usually, the reported bundle size was much larger than it actually was on disk. Why is that?
+If you’ve used other bundle analyzers, you may have noticed results that were significantly off, often showing bundle sizes much larger than they actually were on disk. Why does this happen?
 
-Web bundlers like webpack and Rollup have several hooks that allow plugins to get or modify data at different stages of the bundling process. It is essential for these plugins to run at the right time; otherwise they may break other plugins.
+Web bundlers like webpack and Rollup have various hooks that allow plugins to access or modify data at different stages of the bundling process. It’s crucial for these plugins to execute at the correct stages; otherwise, they could interfere with or break other plugins.
 
 <CustomImage
   src="/blog/rollup_hooks.jpg"
   alt="Graph showing the order of hooks in Rollup"
   caption="The order of hooks in Rollup. Source: https://rollupjs.org"
 />
 
-Let's take two plugins as an example: a plugin that allows you to use different language or syntax in your codebase (like TypeScript or JSX), and a plugin that minifies and optimizes your code. At what stages should these plugins run?
+Consider two plugins: one that transforms code (e.g., TypeScript or JSX to JavaScript) and another that minifies and optimizes the code. The transformation plugin must run before the minification plugin because the latter cannot process TypeScript. Thanks to the hook system, plugins can specify their execution stages, ensuring the correct order in most cases.
 
-If the minification plugin runs before the code is transformed from TypeScript to JavaScript, it will throw an error because it doesn't understand TypeScript. Therefore, the transformation plugin should run before the minification plugin. Fortunately, thanks to the hook system, plugins can specify at which stage they should run, so you don't have to worry about this in most cases (although there are cases where two or more plugins need to run at the same stage, and the order of registration is important).
+### The problem with relying on hooks
 
-What does this have to do with the accuracy of the bundle analyzer?
-
-The problem is that some analyzers try to use the data from the bundler using this hook system. However, because there are steps in the bundling process that must be done at the very end, such as tree-shaking, minification, or obfuscation, the data that these analyzers get is not the final data that is written to disk. As a result, the reported bundle size is often larger than what is actually on disk.
+Some bundle analyzers attempt to gather data directly from the bundler through these hooks. However, critical bundling steps like tree-shaking, minification, and obfuscation occur at the final stages. Analyzers using intermediate data from the hook system often fail to capture these final transformations, leading to inaccurate results that overestimate bundle sizes.
 
 ## How does Sonda solve this problem?
 
-Since we know that the data from the bundler is not the final data, what else can we do? We can wait for the bundler to do its job, and when it's done, use the **source maps** it outputs to analyze the bundles.
+Since the data from bundlers is often incomplete until the final stages, Sonda takes a different approach. Instead of relying solely on the hook system, it waits for the bundler to finish its job and then analyzes the **source maps**.
 
-Source maps are files that allow tracing parts of the final bundle back to the original code. They are generated by the bundler and used by the browser to show you the original code in the developer tools, even though the code that actually runs is minified.
+Source maps trace parts of the final bundle back to the original code. These maps, generated by the bundler, allow browsers to display the original code in developer tools, even if the runtime code is minified.
 
 <CustomImage
   src="/blog/source_map.jpg"
   alt="Arrow pointing a part of minified code back to the original code"
   caption="Tracing minified code back to the original. Source: https://evanw.github.io/source-map-visualization/"
 />
 
-Because source maps tell us where the parts of the final bundle came from, we can use this information to calculate exactly how much each file contributes to the final bundle.
+By analyzing source maps, Sonda can accurately determine how much each file contributes to the final bundle. This method ensures that the reported sizes closely match the actual bundle on disk.
+
+### Does Sonda use the hook system?
+
+Yes, but only for additional context. Sonda uses the hook system to gather non-critical information, such as:
 
-Does this mean that Sonda doesn't use the hook system at all? Actually, it does because not everything can be read from the source maps.
+- A list of parsed source files and their sizes
+- Module format types (ESM, CJS, etc.)
+- Lists of imports
 
-Depending on the bundler, Sonda will read the list of source files the bundler parsed, their sizes, the module format type (ESM, CJS, etc.), and the list of files they import. While this data is not critical to the accuracy of the results, it does give you more context about the bundle, which can be useful when debugging the bundle size.
+This supplementary data helps provide more context for debugging but is not essential for accuracy.
 
 ## Positive side effect of relying on source maps
 
-While working on the initial version of Sonda, I realized that using source maps had a positive side effect. By focusing primarily on source maps, Sonda minimizes dependence on specific bundler internals, so it can work with any bundler. After all, all bundlers can generate source maps, so we have almost all the data we need.
+An unintended benefit of relying primarily on source maps is that Sonda minimizes dependence on specific bundler internals. This design makes Sonda compatible with almost any bundler since all major bundlers can generate source maps.
 
-This is why Sonda works with Vite, Rollup, esbuild, webpack, Rspack, and more bundlers coming soon.
+As a result, Sonda works seamlessly with Vite, Rollup, Rolldown, esbuild, webpack, Rspack, and even more bundlers supported in the future.

docs/bundlers/esbuild.md

@@ -0,0 +1,39 @@
+---
+outline: deep
+---
+
+# Visualizing esbuild bundles with Sonda
+
+To analyze and visualize your esbuild bundles, you need to install the Sonda npm package and add the Sonda plugin to your esbuild configuration.
+
+## Installation
+
+### Install the package
+
+To get started, install the Sonda package using the following command:
+
+```bash
+npm install sonda --save-dev
+```
+
+### Add the plugin and enable source maps
+
+Next, register the Sonda plugin for esbuild and enable source maps:
+
+```js{2,5,7}
+import { build } from 'esbuild';
+import Sonda from 'sonda/esbuild'; // [!code focus]
+
+build( {
+  sourcemap: true, // [!code focus]
+  plugins: [
+    Sonda() // [!code focus]
+  ]
+} );
+```
+
+Sonda requires source maps to function correctly, but some other plugins may not support or generate them by default. If Sonda does not work as expected, check the documentation for the other plugins you are using to ensure source maps are enabled.
+
+### Configure the plugin
+
+The steps above will allow you to generate your first report. However, if the report does not contain the information you need, refer to the [Configuration](/configuration) page to explore additional options and learn how to enable them.

docs/bundlers/rolldown.md

@@ -0,0 +1,45 @@
+---
+outline: deep
+---
+
+# Visualizing Rolldown bundles with Sonda
+
+To analyze and visualize your Rolldown bundles, you need to install the Sonda npm package and add the Sonda plugin to your Rolldown configuration.
+
+## Installation
+
+### Install the package
+
+To get started, install the Sonda package using the following command:
+
+```bash
+npm install sonda --save-dev
+```
+
+### Add the plugin and enable source maps
+
+Next, register the Sonda plugin for Rolldown and enable source maps in the `rolldown.config.js` file:
+
+```js{2,6,9}
+import { defineConfig } from 'rolldown';
+import Sonda from 'sonda/rolldown'; // [!code focus]
+
+export default defineConfig( {
+  output: {
+    sourcemap: true // [!code focus]
+  },
+  plugins: [
+    Sonda() // [!code focus]
+  ]
+} );
+```
+
+Sonda requires source maps to function correctly, but some other plugins may not support or generate them by default. If Sonda does not work as expected, check the documentation for the other plugins you are using to ensure source maps are enabled.
+
+::: warning ⚠️ Rolldown plugin
+Currently, Sonda reports for Rolldown incorrectly display CommonJS modules as ES modules. This is a known limitation and is being tracked in this [GitHub issue](https://github.com/rolldown/rolldown/issues/3002).
+:::
+
+### Configure the plugin
+
+The steps above will allow you to generate your first report. However, if the report does not contain the information you need, refer to the [Configuration](/configuration) page to explore additional options and learn how to enable them.

docs/bundlers/rollup.md

@@ -0,0 +1,41 @@
+---
+outline: deep
+---
+
+# Visualizing Rollup bundles with Sonda
+
+To analyze and visualize your Rollup bundles, you need to install the Sonda npm package and add the Sonda plugin to your Rollup configuration.
+
+## Installation
+
+### Install the package
+
+To get started, install the Sonda package using the following command:
+
+```bash
+npm install sonda --save-dev
+```
+
+### Add the plugin and enable source maps
+
+Next, register the Sonda plugin for Rollup and enable source maps in the `rollup.config.js` file:
+
+```js{2,6,9}
+import { defineConfig } from 'rollup';
+import Sonda from 'sonda/rollup'; // [!code focus]
+
+export default defineConfig( {
+  output: {
+    sourcemap: true // [!code focus]
+  },
+  plugins: [
+    Sonda() // [!code focus]
+  ]
+} );
+```
+
+Sonda requires source maps to function correctly, but some other plugins may not support or generate them by default. If Sonda does not work as expected, check the documentation for the other plugins you are using to ensure source maps are enabled.
+
+### Configure the plugin
+
+The steps above will allow you to generate your first report. However, if the report does not contain the information you need, refer to the [Configuration](/configuration) page to explore additional options and learn how to enable them.

docs/bundlers/rspack.md

@@ -0,0 +1,42 @@
+---
+outline: deep
+---
+
+# Visualizing Rspack bundles with Sonda
+
+To analyze and visualize your Rspack bundles, you need to install the Sonda npm package and add the Sonda plugin to your Rspack configuration.
+
+## Installation
+
+### Install the package
+
+To get started, install the Sonda package using the following command:
+
+```bash
+npm install sonda --save-dev
+```
+
+### Add the plugin and enable source maps
+
+Next, register the Sonda plugin for Rspack and enable source maps in the `rspack.config.js` file:
+
+```js{1,4,6}
+import Sonda from 'sonda/rspack'; // [!code focus]
+
+export default {
+  devtool: 'source-map', // [!code focus]
+  plugins: [
+    new Sonda() // [!code focus]
+  ]
+};
+```
+
+Sonda requires source maps to function correctly, but some other plugins may not support or generate them by default. If Sonda does not work as expected, check the documentation for the other plugins you are using to ensure source maps are enabled.
+
+::: warning ⚠️ Rspack plugin
+Currently, the Sonda plugin for Rspack modifies the default configuration to use absolute paths in the generated source maps instead of webpack-specific paths (`devtoolModuleFilenameTemplate: '[absolute-resource-path]'`). This change may affect how paths appear in browser devtools.
+:::
+
+### Configure the plugin
+
+The steps above will allow you to generate your first report. However, if the report does not contain the information you need, refer to the [Configuration](/configuration) page to explore additional options and learn how to enable them.