@bleedingdev/modern-js-create 3.2.0-ultramodern.97 → 3.2.0-ultramodern.98

package/template-workspace/.agents/skills/rslib-best-practices/SKILL.md

@@ -1,58 +0,0 @@
----
-name: rslib-best-practices
-description: Rslib best practices for config, CLI workflow, output, declaration files, dependency handling, build optimization and toolchain integration. Use when writing, reviewing, or troubleshooting Rslib projects.
----
-
-# Rslib Best Practices
-
-Apply these rules when writing or reviewing Rslib library projects.
-
-## Configuration
-
-- Use `rslib.config.ts` and `defineConfig`
-- Check Rslib-specific configurations first (e.g., `lib.*`), and also leverage Rsbuild configurations (e.g., `source.*`, `output.*`, `tools.*`) as needed
-- For deep-level or advanced configuration needs, use `tools.rspack` or `tools.bundlerChain` to access Rspack's native configurations
-- In TypeScript projects, prefer `tsconfig.json` path aliases
-
-## CLI
-
-- Use `rslib` to build
-- Use `rslib --watch` to build in watch mode for local development
-- Use `rslib inspect` to inspect final Rslib/Rsbuild/Rspack configs
-
-## Output
-
-- Prefer to build pure-ESM package with `"type": "module"` in `package.json`
-- Prefer to use bundleless mode with `output.target` set to `'web'` when building component libraries
-- Prefer to use bundle mode when building Node.js utility libraries
-- Ensure `exports` field in `package.json` is correctly configured and matches the actual JavaScript output and declaration files output of different formats (ESM, CJS, etc.)
-
-## Declaration files
-
-- Prefer to enable declaration file generation with `lib.dts: true` or detailed configurations
-- For faster type generation, enable `lib.dts.tsgo` experimental feature with `@typescript/native-preview` installed
-
-## Dependencies
-
-- Prefer to place dependencies to be bundled in `devDependencies` in bundle mode and dependencies in `dependencies` and `peerDependencies` will be automatically externalized (not bundled) by default
-- Verify the build output and dependency specifiers in `package.json` carefully to ensure no missing dependency errors occur when consumers install and use this package
-
-## Build optimization
-
-- Keep syntax target in `lib.syntax` aligned with real compatibility requirements to enable better optimizations
-- Avoid format-specific APIs in source code for better compatibility with different output formats
-- Prefer lightweight dependencies to reduce bundle size
-
-## Toolchain integration
-
-- Prefer to use Rstest with `@rstest/adapter-rslib` for writing tests
-- Prefer to use Rspress for writing library documentation, with `@rspress/plugin-preview` and `@rspress/plugin-api-docgen` for component previews and API docs
-
-## Debugging
-
-- Run with `DEBUG=rsbuild` when diagnosing config resolution or plugin behavior
-- Read generated files in `dist/.rsbuild` to confirm final Rsbuild/Rspack config, not assumed config
-
-## Documentation
-
-- For the latest Rslib docs, read https://rslib.rs/llms.txt

package/template-workspace/.agents/skills/rslib-modern-package/SKILL.md

@@ -1,173 +0,0 @@
----
-name: rslib-modern-package
-description: Opinionated Rslib recommendations for modern JS/TS npm package design covering pure ESM, strict TypeScript, explicit exports, small stable APIs, pragmatic dependencies, accurate sideEffects, correct declarations, package validation, provenance, README.md, and AGENTS.md. Use when the user wants to make a JS/TS package more modern, check whether the current package setup is healthy, review package.json/exports/types/dependencies/docs/release readiness, or apply a modern library baseline.
----
-
-# Rslib Modern Package
-
-Use this skill when creating a new Rslib library, modernizing an existing JS/TS package, or reviewing a package against an opinionated modern library standard.
-
-This skill is opinionated: it describes a recommended modern package contract and may suggest breaking changes when they make the package simpler, safer, and easier for modern consumers.
-
-## Standard
-
-Default recommendation for new JS/TS libraries:
-
-- ESM-first, preferably pure ESM.
-- Strict TypeScript and correct declaration files.
-- Explicit public API through `package.json#exports`.
-- Small named-export API surface.
-- Few runtime dependencies, without treating zero dependencies as a religion.
-- Small, tree-shakeable output with accurate `sideEffects`.
-- Clear dependency placement: runtime dependencies, peer dependencies, optional dependencies, and dev dependencies are not interchangeable.
-- Published package is tested as an artifact, not just as source files.
-- Release flow is automated, traceable, and SemVer-aware.
-- README.md explains usage for humans; AGENTS.md preserves package invariants for future agents.
-
-## Workflow
-
-1. **Inspect the package contract first**
-   - Read `package.json`, lockfile/package manager, `rslib.config.*`, `tsconfig*`, CI/release config, README.md, AGENTS.md, and existing `dist` output.
-   - Identify package kind: Node utility, browser library, isomorphic utility, CLI, UI/component library, framework plugin, SDK, or adapter.
-   - List supported runtimes, current entry points, deep imports, runtime dependencies, peer dependencies, optional integrations, files with side effects, and published files.
-   - Run `npm pack --dry-run` early when changing package shape so the real tarball contents guide the review.
-
-2. **Define target environments explicitly**
-   - Do not say "supports modern environments" without defining them.
-   - Verify the current Node.js release schedule before choosing `engines`.
-   - As of May 9, 2026, Node.js 22 and 24 are LTS, and Node.js 20 is EOL. For new Node-facing packages, recommend `engines.node >=22` unless real consumers need an older runtime.
-   - Browser packages should state whether they require native ESM, a bundler, Workers support, SSR compatibility, DOM APIs, CSS processing, or specific browser baselines.
-   - Compatibility drops are breaking changes: old Node/browser versions, undocumented deep imports, default/named export shape, bundled vs external dependency behavior, and import side effects.
-
-3. **Prefer pure ESM, but explain compatibility cost**
-   - New packages should use `"type": "module"` and ESM source/output.
-   - Rslib's default format is ESM; keep that default unless there is a clear reason to add another format.
-   - Evaluate compatibility from real consumers and supported runtimes instead of assuming every historical module format is required.
-   - Modern Node.js can load synchronous ESM from CommonJS via `require(esm)`; do not assume CJS consumers always require a separate CJS build.
-   - If you rely on `require(esm)` compatibility, document and test its constraints: supported Node versions, no top-level `await` in the loaded graph, namespace-object return shape, default export behavior, and CJS/ESM cycle limits.
-   - Prefer Node built-in specifiers such as `node:fs/promises`.
-
-4. **Make `exports` the public API**
-   - Treat `package.json#exports` as the product contract.
-   - Export only paths users are meant to import.
-   - Do not allow imports like `pkg/dist/foo.js` by exporting `./dist/*`. That makes the generated output layout part of the public API and turns internal file moves into breaking changes.
-   - Instead, expose only intentional public paths such as `pkg` and `pkg/foo.js`, mapped to the actual files in `dist`.
-   - Keep subpath style consistent: either all with extensions such as `./foo.js`, or all without extensions. Prefer paths with extensions when browser import maps matter.
-   - Keep `"types"` first inside conditional exports.
-   - Adding `exports` to an older package can be breaking because undeclared deep imports stop working.
-   - Add `./package.json` only when consumers legitimately need package metadata.
-
-5. **Design a small API surface**
-   - Prefer named exports for multi-API packages.
-   - Avoid default-export objects that gather every function into one object.
-   - Public functions should be few, stable, well-named, and semver-maintained.
-   - Keep internal types, caches, helper functions, adapter details, and error internals private unless they are part of the contract.
-   - Avoid top-level work during import: file scans, network calls, timers, process mutation, global registration, DOM access, prototype mutation, or environment detection with side effects.
-   - Async APIs that may be canceled should accept `AbortSignal`.
-   - Prefer stable error classes, error codes, or typed error shapes over string matching.
-
-6. **Use Rslib as the implementation path, not the whole standard**
-   - For detailed Rslib configuration guidance, use the `rslib-best-practices` skill.
-   - In this skill, only check whether Rslib output, declarations, `package.json#exports`, `files`, dependencies, and docs agree with the modern package contract.
-   - Keep Rslib configuration small and intentional; avoid adding build complexity that does not improve the package contract.
-
-7. **Keep dependencies small and intentional**
-   - Start from platform APIs, not from dependency search.
-   - Prefer built-ins when the runtime supports them: `URL`, `URLSearchParams`, `Intl`, `fetch`, `AbortController`, `structuredClone`, `crypto.randomUUID`, Web Streams, `TextEncoder`, `TextDecoder`, `node:fs/promises`, and `node:crypto`.
-   - Small runtime dependencies are fine when they reduce maintenance risk or implementation complexity.
-   - Avoid large utility packages for one or two helpers.
-   - Evaluate dependencies for ESM support, `exports`, types, transitive dependency count, package size, license, maintenance activity, security history, install scripts, side effects, native install fragility, and granular imports.
-   - Put required runtime packages in `dependencies`.
-   - Put host-owned frameworks and toolchains in `peerDependencies`, such as React, Vue, Svelte, Rspack, Rsbuild, webpack, TypeScript, and framework runtimes.
-   - Keep peer ranges reasonably broad; do not pin peers to a patch version unless required.
-   - Put build tools, test tools, type tools, docs tools, and Rsbuild/Rspack plugins in `devDependencies`.
-   - Use `optionalDependencies` or optional peers via `peerDependenciesMeta` for optional integrations.
-
-8. **Make TypeScript strict and package-oriented**
-   - Prefer TypeScript source for TS libraries; otherwise use high-quality JSDoc plus generated declarations.
-   - With TypeScript 6 or tsgo-era defaults, strict checking may already be enabled; preserve that default and do not turn it off. For older TypeScript versions or inherited configs, set `strict: true` explicitly.
-   - In Rslib projects, consider enabling `lib.dts.tsgo` to speed up declaration generation when the project can use tsgo.
-   - Keep `module` and `moduleResolution` aligned with how declarations are emitted and how consumers resolve the package; NodeNext and bundler-style resolution are both valid in the right toolchain.
-   - Use `verbatimModuleSyntax` so type-only imports/exports are explicit.
-   - Use `isolatedDeclarations` when practical so exported APIs are explicit enough for declaration-oriented tooling.
-   - Emit declarations; use declaration maps when editor navigation matters.
-   - Use `import type` and `export type` for type-only dependencies.
-   - Do not rely on consumers setting `skipLibCheck` to hide broken package types.
-   - Test declarations as consumers see them, especially when using subpath exports.
-
-9. **Keep `sideEffects` accurate**
-   - Use `sideEffects: false` only when importing package files has no top-level side effects.
-   - If CSS, polyfills, registrations, global listeners, prototype changes, or other import-time mutations exist, list the files with side effects instead.
-   - Do not set `sideEffects: false` just to improve bundle size; incorrect values can remove required CSS or setup code.
-   - Do not change globals just because a file is imported. If setup is required, expose an explicit `setup()` or `install()` function and let users call it themselves.
-
-10. **Make `package.json` authoritative**
-    - Required modern shape: `"type": "module"`, explicit `exports`, correct declarations, `files` allowlist, accurate `sideEffects`, sensible `engines`, and release scripts.
-    - Include README.md, AGENTS.md, and LICENSE in `files` when they exist.
-    - `files` should prevent tests, fixtures, private docs, build caches, local configs, and large generated artifacts from leaking into the tarball.
-    - Avoid stale `main`/`module` fields unless compatibility evidence requires them; if kept, they must agree with `exports`.
-    - Keep runtime dependency fields accurate. A package that works locally only because a runtime dependency is in `devDependencies` is broken.
-
-11. **Validate the published artifact**
-    - Run normal lint, typecheck, tests, and `rslib build`.
-    - Smoke test built ESM output.
-    - Run type-level tests when the public API is type-heavy.
-    - Run `npm pack --dry-run` and inspect included files.
-    - In Rslib, prefer `rsbuild-plugin-publint` to run publint after build; use `npx publint` as a CLI fallback.
-    - In Rslib, prefer `rsbuild-plugin-arethetypeswrong` to run Are The Types Wrong after build when declarations are shipped; use `npx --yes @arethetypeswrong/cli --pack .` as a CLI fallback.
-    - Install the packed tarball into clean consumer fixtures for important packages.
-    - Test ESM import, bundler import for browser/component libraries, CLI execution for `bin` packages, and every public subpath export.
-
-12. **Prepare README.md and AGENTS.md before publishing**
-    - Always check whether both files exist before publishing or modernizing a package.
-    - If either file is missing, recommend adding it; for implementation tasks, create a concise version unless the user asks not to.
-    - README.md should include: package name, one-sentence purpose, install/usage, key features or API links, supported environments, docs/related links, changelog or contribution link, and license.
-    - AGENTS.md should include: stack, package contract, common commands, source layout, code style, validation commands, and release checklist.
-    - Keep both files synchronized with `package.json#exports`, supported runtimes, and actual Rslib output.
-
-13. **Publish with supply-chain hygiene**
-    - Follow SemVer and document breaking changes.
-    - Maintain a changelog for user-visible changes.
-    - Use prerelease versions and dist-tags for beta/next channels.
-    - Prefer CI publishing with npm provenance or trusted publishing.
-    - Avoid long-lived publish tokens where trusted publishing is available.
-    - Remember that a published package name/version pair cannot be reused safely.
-
-## Review Red Flags
-
-- `exports` is missing, points to files not emitted by Rslib, or allows public imports such as `pkg/dist/foo.js`.
-- `module`/`main` fields disagree with `exports`.
-- Type declarations do not match runtime entry points.
-- Runtime dependency is accidentally listed only in `devDependencies`.
-- React/Vue/Svelte/Rspack/Rsbuild/webpack/TypeScript is bundled or placed in `dependencies` when it should be a peer.
-- `sideEffects: false` is set while importing CSS, polyfills, global registrations, global listeners, or prototype changes.
-- Package has install scripts without a strong reason.
-- Top-level import reads user files, starts timers, touches the network, mutates globals, or assumes `window`/`process`.
-- Published tarball contains private source maps, tests/fixtures that are not useful to consumers, large generated docs, local config secrets, or build caches.
-
-## Checklist
-
-- [ ] Supported environments are explicit.
-- [ ] Package is ESM-first, preferably pure ESM.
-- [ ] `package.json` has `"type": "module"`.
-- [ ] Public entry points are declared in `exports`.
-- [ ] No accidental reliance on undeclared deep imports.
-- [ ] Rslib output, declarations, `exports`, and `files` agree.
-- [ ] TypeScript strict mode is enabled.
-- [ ] Declarations are emitted and validated.
-- [ ] Runtime dependencies are justified and small.
-- [ ] Host frameworks/toolchains are peers.
-- [ ] Build/test/type/docs tools are dev dependencies.
-- [ ] `sideEffects` is accurate.
-- [ ] `npm pack --dry-run` has been inspected.
-- [ ] `publint` passes.
-- [ ] Are The Types Wrong check passes when declarations are shipped.
-- [ ] Built ESM smoke test passes.
-- [ ] README.md exists.
-- [ ] AGENTS.md exists.
-- [ ] Release flow uses SemVer, changelog, and provenance/trusted publishing when available.
-
-## Documentation
-
-- For the latest Rslib docs, read https://rslib.rs/llms.txt
-- Shipping ESM for CommonJS consumers: https://nodejs.github.io/package-examples/04-cjs-esm-interop/shipping-esm-for-cjs/

package/template-workspace/.agents/skills/rspack-best-practices/SKILL.md

@@ -1,70 +0,0 @@
----
-name: rspack-best-practices
-description: Rspack best practices for config, CLI workflow, type checking, CSS, bundle optimization, assets and profiling. Use when writing, reviewing, or troubleshooting Rspack projects.
----
-
-# Rspack Best Practices
-
-Apply these rules when writing or reviewing Rspack projects.
-
-## Configuration
-
-- Use `rspack.config.ts` and `defineConfig`
-- Define explicit `entry` values for multi-page applications
-- Keep one main config and branch by `process.env.NODE_ENV` only when needed
-- Keep rule conditions narrow and explicit (`test`, `include`, `exclude`, `resourceQuery`)
-- Prefer built-in Rspack plugins/loaders over community JS alternatives when equivalent features exist
-
-## CLI
-
-If `@rspack/cli` is installed:
-
-- Use `rspack dev` for local development
-- Use `rspack build` for production build
-- Use `rspack preview` only for local production preview
-
-## Type checking
-
-- Use `ts-checker-rspack-plugin` for integrated dev/build type checks
-- Or run `tsc --noEmit`/`vue-tsc --noEmit` as an explicit script step
-
-## CSS
-
-Choose one strategy:
-
-- Built-in CSS (`type: 'css' | 'css/auto' | 'css/module'`) for modern setups
-- `css-loader` + `CssExtractRspackPlugin` for webpack migration compatibility
-- `style-loader` for pure style-in-JS runtime injection scenarios
-
-Optional:
-
-- Use `builtin:lightningcss-loader` when goals are syntax downgrade + vendor prefixing
-- Use `sass-loader`/`less-loader` for preprocessing Sass/Less files
-- Use `@tailwindcss/webpack` for Tailwind CSS integration
-
-## Bundle size optimization
-
-- Prefer dynamic `import()` for non-critical code paths
-- Prefer lightweight libraries where possible
-- Keep `target` aligned with real compatibility requirements
-
-## Asset management
-
-- Import source-managed assets from project source directories, not from `public`
-- Reference `public` files by absolute URL path
-- Prefer asset modules (`asset`, `asset/resource`, `asset/inline`, `asset/source`) over legacy `file-loader`/`url-loader`/`raw-loader`
-
-## Profiling
-
-- Use Node CPU profiling (`--cpu-prof`) when JavaScript-side overhead is suspected
-- Use `RSPACK_PROFILE=OVERVIEW` and analyze trace output for compiler-phase bottlenecks
-- Replace known slow stacks first (`babel-loader`, PostCSS, terser) with Rspack built-ins when feasible
-
-## Security
-
-- Do not publish `.map` files to public servers/CDNs when production source maps are enabled
-
-## Documentation
-
-- For the latest (v2) docs, read http://rspack.rs/llms.txt
-- For Rspack v1 docs, read http://v1.rspack.rs/llms.txt

package/template-workspace/.agents/skills/rspack-tracing/SKILL.md

@@ -1,75 +0,0 @@
----
-name: rspack-tracing
-description: Comprehensive guide and toolkit for diagnosing Rspack build issues. Quickly identify where crashes/errors occur, or perform detailed performance profiling to resolve bottlenecks. Use when the user encounters build failures, slow builds, or wants to optimize Rspack performance.
----
-
-# Rspack Tracing & Performance Profiling
-
-## When to Use This Skill
-
-Use this skill when you need to:
-
-1.  Diagnose why an Rspack build is slow.
-2.  Understand which plugins or loaders are taking the most time.
-3.  Analyze a user-provided Rspack trace file.
-4.  Guide a user to capture a performance profile.
-
-## Workflow
-
-### 1. Capture a Trace
-
-First, ask the user to run their build with tracing enabled.
-
-```bash
-# Set environment variables for logging to a file
-RSPACK_PROFILE=TRACE RSPACK_TRACE_LAYER=logger RSPACK_TRACE_OUTPUT=./trace.json pnpm build
-```
-
-This will generate a trace file in a timestamped directory like `.rspack-profile-{timestamp}-{pid}/trace.json`.
-
-See [references/tracing-guide.md](references/tracing-guide.md) for more details on configuration.
-
-### 2. Quick Diagnosis for Crashes/Errors
-
-If the user wants to identify **which stage a crash or error occurred in**, use `tail` to quickly view the last events without running the full analysis:
-
-```bash
-# Navigate to the generated profile directory
-cd .rspack-profile-*/
-
-# View the last 20 events to see where the build failed
-tail -n 20 trace.json
-```
-
-The last events will show the span names and targets where the build stopped, helping to quickly pinpoint the problematic stage, plugin, or loader.
-
-### 3. Full Performance Analysis
-
-For detailed performance profiling (not just crash diagnosis), ask the user to run the bundled analysis script on the generated trace file.
-
-```bash
-# Navigate to the generated profile directory
-cd .rspack-profile-*/
-
-# Run the analysis script
-node ${CLAUDE_PLUGIN_ROOT}/skills/tracing/scripts/analyze_trace.js trace.json
-```
-
-### 4. Interpret Results
-
-Use the output from the script to identify bottlenecks.
-Consult [references/bottlenecks.md](references/bottlenecks.md) to map span names to actionable fixes.
-
-### 5. Locate Slow Plugins
-
-Based on the "Top Slowest Hooks" from the analysis script:
-
-1.  **Identify the Hook**: Note the hook name (e.g., `hook:CompilationOptimizeChunks`).
-2.  **Inspect Configuration**: Read `rspack.config.js` or `rsbuild.config.ts`.
-3.  **Map Hook to Plugin**: Look for plugins and their sources that tap into that specific hook.
-4.  **Output**: Output the paths, lines and columns of the suspected plugin source code.
-
-## Common Scenarios & Quick Fixes
-
-- [Bottleneck Reference](references/bottlenecks.md): Mapping spans to concepts.
-- [Tracing Guide](references/tracing-guide.md): Detailed usage of `RSPACK_PROFILE`.

package/template-workspace/.agents/skills/rspack-tracing/references/bottlenecks.md

@@ -1,47 +0,0 @@
-# Understanding Rspack Performance Bottlenecks
-
-This reference maps internal Rspack tracing spans to high-level concepts to help you identify performance issues.
-
-## Core Compilation Phases
-
-| Span Name               | Description                                                    | Potential Bottlenecks                                                             |
-| :---------------------- | :------------------------------------------------------------- | :-------------------------------------------------------------------------------- |
-| `tracing::profiling`    | The entire build process.                                      | Overall slowness.                                                                 |
-| `compiler::make`        | **Make Phase**: Resolving, loading, and parsing modules.       | Heavy loaders (babel/swc with complex configs), too many files, slow file system. |
-| `compiler::seal`        | **Seal Phase**: Optimizing, splitting chunks, generating code. | Complex code splitting, heavy minification, many modules.                         |
-| `compiler::emit_assets` | **Emit Phase**: Writing files to disk.                         | Slow disk I/O, huge output files.                                                 |
-
-## Detailed Spans
-
-### Make Phase (Module Processing)
-
-- `resolver::resolve`: Resolving import paths.
-  - **High Time?**: Check for complex `resolve.alias` or `resolve.modules`, or too many standard fallbacks.
-- `loader::run_loaders`: Executing loaders (JavaScript/Rust).
-  - **High Time?**: Identify which loader is slow. If `sass-loader` or `babel-loader` is slow, consider caching (`cache: true` in config) or using `swc-loader`.
-- `parser::parse`: Parsing source code into AST.
-  - **High Time?**: Large files?
-
-### Seal Phase (Optimization)
-
-- `compilation::code_generation`: Generating final code from AST.
-- `compilation::optimize_chunks`: Splitting chunks (SplitChunksPlugin).
-  - `k_means_splitter`: If you see this, complex splitting logic is running.
-- `js_minimizer`: Minification (SwcJsMinimizer).
-  - **High Time?**: Disable minimization in dev (`optimization.minimize: false`) for speed.
-
-### General
-
-- `read_file`: Reading files from disk.
-- `write_file`: Writing artifacts to disk.
-
-## Common Fixes
-
-1.  **Slow `make` phase**:
-    - Use `experiments.cache` (Persistent Cache).
-    - Exclude `node_modules` from expensive loaders.
-    - Switch to lighter loaders (e.g. `swc-loader` vs `babel-loader`).
-2.  **Slow `seal` phase**:
-    - Reduce `splitChunks` complexity.
-    - Disable `sourcemap` in production if acceptable cost.
-    - Upgrade to latest Rspack (performance improvements are frequent).

package/template-workspace/.agents/skills/rspack-tracing/references/tracing-guide.md

@@ -1,38 +0,0 @@
-# Rspack Tracing Guide
-
-Tracing allows you to visualize exactly what Rspack is doing during a build.
-
-## Enabling Tracing
-
-Rspack uses several environment variables to control tracing.
-
-**Command:**
-
-```bash
-RSPACK_PROFILE=TRACE RSPACK_TRACE_LAYER=logger RSPACK_TRACE_OUTPUT=./trace.json rspack build
-```
-
-### Variables
-
-**`RSPACK_PROFILE`**: Controls the granularity of the trace.
-
-- `TRACE`: Captures all spans. (Recommended for deep analysis)
-- `DEBUG`, `INFO`, `WARN`, `ERROR`, `CRITICAL`
-- `OFF`: Disables tracing.
-
-**`RSPACK_TRACE_LAYER`**: Controls the output format.
-
-- `logger`: Outputs standard JSON logging (required for the analysis script).
-
-## Output
-
-After running the command, Rspack will generate the file specified in `RSPACK_TRACE_OUTPUT`.
-
-## Using the Skill's Analysis Tool
-
-This skill includes a script to summarize the trace file.
-
-```bash
-# Run the included script
-node scripts/analyze_trace.js <path-to-trace-file>
-```

package/template-workspace/.agents/skills/rspack-tracing/scripts/analyze_trace.js

@@ -1,184 +0,0 @@
-#!/usr/bin/env node
-
-const fs = require('fs');
-const path = require('path');
-
-// Parse duration string (e.g., "1.23ms", "456.78µs", "0.12s") to milliseconds
-function parseDuration(durationStr) {
-  if (!durationStr) return 0;
-
-  const match = durationStr.match(/^([\d.]+)(ms|µs|s|ns)$/);
-  if (!match) return 0;
-
-  const value = parseFloat(match[1]);
-  const unit = match[2];
-
-  switch (unit) {
-    case 's':
-      return value * 1000;
-    case 'ms':
-      return value;
-    case 'µs':
-      return value / 1000;
-    case 'ns':
-      return value / 1000000;
-    default:
-      return value;
-  }
-}
-
-// Get trace file path
-const tracePath = process.argv[2] || path.join(__dirname, 'trace.json');
-
-if (!fs.existsSync(tracePath)) {
-  console.error(`Error: Trace file not found at ${tracePath}`);
-  console.error('Usage: node analyze_trace.js <path-to-trace.json>');
-  process.exit(1);
-}
-
-console.log(`Analyzing trace file: ${tracePath}\n`);
-
-try {
-  const fileContent = fs.readFileSync(tracePath, 'utf8');
-
-  // Parse line-delimited JSON
-  const events = fileContent
-    .trim()
-    .split('\n')
-    .map(line => {
-      try {
-        return JSON.parse(line);
-      } catch (err) {
-        return null;
-      }
-    })
-    .filter(Boolean);
-
-  if (!events.length) {
-    console.error('No valid trace events found.');
-    process.exit(1);
-  }
-
-  console.log('=== Rspack Build Performance Analysis ===\n');
-  console.log(`Total events: ${events.length}\n`);
-
-  // Categorize events by target
-  const pluginStats = new Map();
-  const loaderStats = new Map();
-
-  events.forEach(event => {
-    const target = event.target;
-    const timeField = event.fields?.['time.busy'];
-
-    if (!timeField) return;
-
-    const duration = parseDuration(timeField);
-
-    if (target === 'Plugin Analysis') {
-      // Plugin performance
-      const pluginName = event.span?.name;
-      if (!pluginName) return;
-
-      if (!pluginStats.has(pluginName)) {
-        pluginStats.set(pluginName, {
-          count: 0,
-          total: 0,
-          max: 0,
-          min: Infinity,
-        });
-      }
-
-      const stat = pluginStats.get(pluginName);
-      stat.count++;
-      stat.total += duration;
-      stat.max = Math.max(stat.max, duration);
-      stat.min = Math.min(stat.min, duration);
-    } else if (target === 'Loader Analysis') {
-      // Loader performance
-      let loaderName = event.span?.name;
-
-      // For pitch phase (span.name is null), use resource path
-      if (!loaderName) {
-        const resource = event.fields?.resource;
-        if (resource) {
-          // Extract filename from resource path
-          const cleanResource = resource.replace(/^"|"$/g, ''); // Remove quotes
-          const filename = cleanResource.split('/').pop();
-          loaderName = `Loader pitch for ${filename}`;
-        } else {
-          loaderName = 'Loader pitch (unknown resource)';
-        }
-      }
-
-      if (!loaderStats.has(loaderName)) {
-        loaderStats.set(loaderName, {
-          count: 0,
-          total: 0,
-          max: 0,
-          min: Infinity,
-        });
-      }
-
-      const stat = loaderStats.get(loaderName);
-      stat.count++;
-      stat.total += duration;
-      stat.max = Math.max(stat.max, duration);
-      stat.min = Math.min(stat.min, duration);
-    }
-  });
-
-  // Display Plugin Analysis
-  if (pluginStats.size > 0) {
-    console.log('🔌 Plugin Analysis (by name):');
-    console.log('─'.repeat(80));
-
-    const sortedPlugins = [...pluginStats.entries()].sort(
-      (a, b) => b[1].total - a[1].total,
-    );
-
-    sortedPlugins.forEach(([name, stat]) => {
-      const avg = stat.total / stat.count;
-      console.log(`${name}`);
-      console.log(
-        `  Total: ${stat.total.toFixed(2)}ms | Count: ${stat.count} | ` +
-          `Avg: ${avg.toFixed(2)}ms | Max: ${stat.max.toFixed(2)}ms | Min: ${stat.min.toFixed(2)}ms`,
-      );
-      console.log('');
-    });
-
-    const totalPluginTime = [...pluginStats.values()].reduce(
-      (sum, stat) => sum + stat.total,
-      0,
-    );
-    console.log(`Total Plugin Time: ${totalPluginTime.toFixed(2)}ms\n`);
-  }
-
-  // Display Loader Analysis
-  if (loaderStats.size > 0) {
-    console.log('\n🔧 Loader Analysis (by name):');
-    console.log('─'.repeat(80));
-
-    const sortedLoaders = [...loaderStats.entries()].sort(
-      (a, b) => b[1].total - a[1].total,
-    );
-
-    sortedLoaders.forEach(([name, stat]) => {
-      const avg = stat.total / stat.count;
-      console.log(`${name}`);
-      console.log(
-        `  Total: ${stat.total.toFixed(2)}ms | Count: ${stat.count} | ` +
-          `Avg: ${avg.toFixed(2)}ms | Max: ${stat.max.toFixed(2)}ms | Min: ${stat.min.toFixed(2)}ms`,
-      );
-      console.log('');
-    });
-
-    const totalLoaderTime = [...loaderStats.values()].reduce(
-      (sum, stat) => sum + stat.total,
-      0,
-    );
-    console.log(`Total Loader Time: ${totalLoaderTime.toFixed(2)}ms\n`);
-  }
-} catch (err) {
-  console.error('Error processing trace file:', err);
-  process.exit(1);
-}