### Starting Development Server with npm/yarn/pnpm

Source: https://github.com/shuvijs/shuvi/blob/main/packages/create-shuvi/templates/typescript/README-template.md

This snippet provides commands to start the development server for a Shuvi.js project using different package managers: npm, yarn, or pnpm. The server will typically run on http://localhost:3000, allowing for live updates as files are edited.

```bash
npm run dev
# or
yarn dev
# or
pnpm dev
```

--------------------------------

### Running Development Server with Shuvi.js (Bash)

Source: https://github.com/shuvijs/shuvi/blob/main/packages/create-shuvi/templates/default/README-template.md

This snippet provides commands to start the development server for a Shuvi.js project using common package managers. The server typically runs on http://localhost:3000, enabling live updates as files are edited.

```bash
npm run dev
# or
yarn dev
# or
pnpm dev
```

--------------------------------

### Installing Cargo (Rust Package Manager) - Bash

Source: https://github.com/shuvijs/shuvi/blob/main/CONTRIBUTING.md

This snippet provides the command to install Cargo, the Rust package manager, using a curl script. It's a prerequisite for certain aspects of the Shuvi project, likely related to tooling or dependencies that rely on Rust.

```Bash
$ curl https://sh.rustup.rs -sSf | sh
```

--------------------------------

### Initial Page Exporting Component and Loader

Source: https://github.com/shuvijs/shuvi/blob/main/test/fixtures/loader-tree-shaking/README.md

This snippet shows the initial setup where `routes/A/page` exports both the `default` component and the `loader` function from `./component`. This combined export contributes to the tree-shaking issue when only the loader is intended for use.

```js
export { default, loader } from './component'
```

--------------------------------

### Organizing Type Files in JavaScript

Source: https://github.com/shuvijs/shuvi/blob/main/CODESTYLE.md

This snippet illustrates the recommended file organization for type definitions in JavaScript projects. It advocates for co-locating type files (e.g., 'a.type.js') with their corresponding implementation files ('a.js') and using a central 'types.js' for re-exporting, which simplifies deletion and improves maintainability.

```JavaScript
// bad
types.js
a.js
b.js

// good
a.js
a.type.js
b.js
b.type.js
types.js // re-export a.types.js & b.types.js
```

--------------------------------

### Module Access Patterns in JavaScript

Source: https://github.com/shuvijs/shuvi/blob/main/CODESTYLE.md

This snippet demonstrates the preferred way to access modules, discouraging direct subpath imports. It promotes using an 'index.js' file within a module directory to re-export necessary components, thereby treating the folder as a single module and hiding internal implementation details, which enhances encapsulation and simplifies refactoring.

```JavaScript
// bad
|- a
  |- a1.js
  |- a2.js

import a1 from 'a/a1';

// good
|- a
  |- a1.js
  |- a2.js
  |- index.js // re-export a1.js & a2.js

import { a1 } from 'a';
```

--------------------------------

### Solution 2: Recursive Loader - Page Re-export (Old)

Source: https://github.com/shuvijs/shuvi/blob/main/test/fixtures/loader-tree-shaking/README.md

This snippet illustrates the original `page` module re-exporting both `default` and `loader` from a nested path. This is the starting point for Solution 2, which aims to transform such re-exports to isolate the loader.

```js
export { default, loader } from './xx/page'
```

--------------------------------

### Initializing Shuvi.js Project with create-shuvi (Default)

Source: https://github.com/shuvijs/shuvi/blob/main/packages/create-shuvi/README.md

This snippet demonstrates how to create a new Shuvi.js application using the `create-shuvi` CLI tool with default settings. It provides commands for `npx`, `yarn`, and `pnpm`.

```bash
npx create-shuvi@latest
# or
yarn create shuvi
# or
pnpm create shuvi
```

--------------------------------

### Building Production Binary with NAPI

Source: https://github.com/shuvijs/shuvi/blob/main/packages/compiler-swc/READEME.md

This command builds the production-ready version of the shuvi project's binary using NAPI. The '--release' flag optimizes the build for performance, targeting a specific platform and using 'build/swc' as the cargo working directory, requiring a path to be specified.

```Shell
npx napi build --platform --cargo-cwd build/swc ${Your Path} --release
```

--------------------------------

### Initializing Shuvi.js Project with create-shuvi (TypeScript)

Source: https://github.com/shuvijs/shuvi/blob/main/packages/create-shuvi/README.md

This snippet shows how to initialize a new Shuvi.js application specifically configured for TypeScript using the `create-shuvi` CLI. It includes commands for `npx`, `yarn`, and `pnpm` with the `--typescript` flag.

```bash
npx create-shuvi@latest --typescript
# or
yarn create shuvi --typescript
# or
pnpm create shuvi --typescript
```

--------------------------------

### Building Development Binary with NAPI

Source: https://github.com/shuvijs/shuvi/blob/main/packages/compiler-swc/READEME.md

This command builds the development version of the shuvi project's binary using NAPI. It targets a specific platform and uses the 'build/swc' directory as the cargo working directory, requiring a path to be specified.

```Shell
npx napi build --platform --cargo-cwd build/swc ${Your Path}
```

--------------------------------

### Initializing Shuvi.js Project in a Specific Folder

Source: https://github.com/shuvijs/shuvi/blob/main/packages/create-shuvi/README.md

This snippet illustrates how to create a new Shuvi.js application within a designated folder using `create-shuvi`. By providing a name as an argument (e.g., `my-first-app`), the CLI will create a new directory with that name and initialize the project inside it.

```bash
npx create-shuvi@latest my-first-app
# or
yarn create shuvi my-first-app
# or
pnpm create shuvi my-first-app
```

--------------------------------

### Running Rust Tests

Source: https://github.com/shuvijs/shuvi/blob/main/packages/compiler-swc/READEME.md

This command executes the test suite for the Rust components of the shuvi project. It ensures that all functionalities are working as expected during development.

```Shell
cargo test
```

--------------------------------

### Running Shuvi CLI in Development - Bash

Source: https://github.com/shuvijs/shuvi/blob/main/CONTRIBUTING.md

This command demonstrates how to run the Shuvi CLI in development mode for a specific application directory. It uses `pnpm` to execute the `shuvi` command, serving the application located at `test/fixtures/basic`.

```Bash
pnpm shuvi dev test/fixtures/basic
```

--------------------------------

### Solution 2: Recursive Loader - Page Export (Old)

Source: https://github.com/shuvijs/shuvi/blob/main/test/fixtures/loader-tree-shaking/README.md

This snippet presents a simplified `page` export of `loader` from a relative path. It represents another common pattern that Solution 2 needs to address by adding the `?shuvi-page-loader` query during transformation.

```js
export { loader } from './xx'
```

--------------------------------

### Initial Component and Loader Definition

Source: https://github.com/shuvijs/shuvi/blob/main/test/fixtures/loader-tree-shaking/README.md

This code defines the `Component` function, which uses `useLoaderData` to access data, and the `loader` function, which returns a simple object. Both are exported from `./component`, serving as the source for the page's combined export.

```js
import { useLoaderData } from '@shuvi/runtime';

export default function Component() {
  const data = useLoaderData();
  return (
    <div id="content">
      {data.loader}
    </div>
  );
}

export function loader(ctx) {
  return {
    loader: '111'
  };
}
```

--------------------------------

### Solution 2: Recursive Loader - Any Module Re-export (Old)

Source: https://github.com/shuvijs/shuvi/blob/main/test/fixtures/loader-tree-shaking/README.md

This snippet illustrates a scenario where a `page` re-exports a `loader` from an `anyModule` with the `?shuvi-page-loader` query already applied. This indicates a chain of re-exports that SWC needs to follow.

```js
export { loader } from './anyModule?shuvi-page-loader'
```

--------------------------------

### Solution 2: Recursive Loader - Page Loaders Import

Source: https://github.com/shuvijs/shuvi/blob/main/test/fixtures/loader-tree-shaking/README.md

This snippet shows how `page-loaders.js` imports the loader using a special `?shuvi-page-loader` query. This query is crucial for Solution 2, signaling that only the loader content should be extracted and bundled.

```js
import { loader as loader_0 } from 'src/routes/xx/page?shuvi-page-loader'
```

--------------------------------

### Configuring ErrorOverlay and Triggering Runtime Error in JavaScript

Source: https://github.com/shuvijs/shuvi/blob/main/packages/error-overlay/playground/runtime-error.html

This snippet demonstrates how to initialize an ErrorOverlay for runtime error reporting, specifically setting up an onError callback to log a 'test' message. It then immediately throws a new Error to simulate a runtime error, which would typically be caught and reported by the configured overlay.

```JavaScript
ErrorOverlay.startReportingRuntimeErrors({onError:()=>{console.log('test')}});throw Error('runtime error');
```

--------------------------------

### Solution 2: Recursive Loader - Final Loader Content

Source: https://github.com/shuvijs/shuvi/blob/main/test/fixtures/loader-tree-shaking/README.md

This snippet represents the final extracted `loader` content from the `routes/A/component` module, accessed via the `?shuvi-page-loader` query. This is the desired outcome of Solution 2, where only the essential loader function is bundled.

```js
export function loader(ctx) {
  return {
    loader: '111'
  };
}
```

--------------------------------

### Solution 2: Recursive Loader - Page Export (New)

Source: https://github.com/shuvijs/shuvi/blob/main/test/fixtures/loader-tree-shaking/README.md

This snippet shows the transformed `page` export, where the `?shuvi-page-loader` query has been added to the re-exported loader path. This modification, performed by SWC, ensures that only the loader content is processed.

```js
export { loader } from './xx?shuvi-page-loader'
```

--------------------------------

### Solution 2: Loader Re-export Case 1 - Source

Source: https://github.com/shuvijs/shuvi/blob/main/test/fixtures/loader-tree-shaking/README.md

This is the source code for Case 1, demonstrating a common pattern where both `default` and `loader` are re-exported from a nested page. This case is expected to be handled by SWC transformations.

```js
export { default, loader } from './xx/page'
```

--------------------------------

### Solution 2: Loader Re-export Case 2 - Source

Source: https://github.com/shuvijs/shuvi/blob/main/test/fixtures/loader-tree-shaking/README.md

This is the source code for Case 2, where the `default` export is re-exported as `loader`. This specific re-export pattern is noted as a limitation, as SWC is currently unable to handle it for transformation.

```js
export { default as loader } from './xx'
```

--------------------------------

### Solution 1: Virtual Module - Loader Export

Source: https://github.com/shuvijs/shuvi/blob/main/test/fixtures/loader-tree-shaking/README.md

This snippet demonstrates the dedicated `loader` module in Solution 1, which exports the `loader` function from a `virtual/component`. This approach isolates the loader logic, allowing it to be bundled separately without the `default` component.

```js
export { loader } from 'virtual/component'
```

--------------------------------

### Solution 2: Loader Re-export Case 1 - Expected

Source: https://github.com/shuvijs/shuvi/blob/main/test/fixtures/loader-tree-shaking/README.md

This snippet shows the expected transformed code for Case 1, where only `loader` is re-exported with the `?shuvi-page-loader` query. This transformation isolates the loader for efficient bundling.

```js
export { loader } from './xx/page?shuvi-page-loader’
```

--------------------------------

### Solution 2: Loader Re-export Case 2 - Expected

Source: https://github.com/shuvijs/shuvi/blob/main/test/fixtures/loader-tree-shaking/README.md

This snippet shows the expected result for Case 2, which is identical to the source code. This highlights a current limitation where SWC cannot transform this specific re-export pattern, causing recursion interruption.

```js
export { default as loader } from './xx'
```

--------------------------------

### Solution 2: Recursive Loader - Any Module Re-export (Transformed)

Source: https://github.com/shuvijs/shuvi/blob/main/test/fixtures/loader-tree-shaking/README.md

This snippet shows the `anyModule` re-exporting `loader` from `routes/A/component`. In the context of Solution 2, SWC would transform this re-export by adding the `?shuvi-page-loader` query to the path, ensuring proper loader extraction.

```js
export { loader } from './routes/A/component'
```

--------------------------------

### Solution 2: Loader Re-export Case 3 - Expected

Source: https://github.com/shuvijs/shuvi/blob/main/test/fixtures/loader-tree-shaking/README.md

This snippet shows the expected result for Case 3, which is identical to the source code. This confirms that SWC is unable to transform this pattern, leading to an interruption in the recursive loader extraction process.

```js
Import { a } from './xx'
export const loader = a
```

--------------------------------

### Handling Build Errors with ErrorOverlay in JavaScript

Source: https://github.com/shuvijs/shuvi/blob/main/packages/error-overlay/playground/build-error.html

This snippet demonstrates how the `ErrorOverlay.onBuildError` function is invoked to report a build error. It's typically used by the build system to display an error overlay to the developer, providing immediate feedback on compilation issues. The function takes a string argument representing the error message.

```JavaScript
ErrorOverlay.onBuildError('Build Error')
```

--------------------------------

### Configuring ES Module Type in package.json (JSON)

Source: https://github.com/shuvijs/shuvi/blob/main/examples/package-esmodule/README.md

This snippet configures a Node.js package to be an ES module by setting the 'type' field to 'module' in the package.json file. This allows the use of `import` and `export` statements without requiring a specific file extension like `.mjs`.

```JSON
{
  "type": "module"
}
```

--------------------------------

### Solution 1: Virtual Module - Page Export

Source: https://github.com/shuvijs/shuvi/blob/main/test/fixtures/loader-tree-shaking/README.md

As part of the virtual module solution, this snippet shows the `page` module now only exporting the `default` component from `./component`. This separation aims to prevent the `default` export from being included in the `loader.js` chunk.

```js
export { default } from './component'
```

--------------------------------

### Solution 1: Virtual Module - Virtual Component Content

Source: https://github.com/shuvijs/shuvi/blob/main/test/fixtures/loader-tree-shaking/README.md

This code defines the content of the `virtual/component`, which exclusively contains the `loader` function. This virtual module serves as the isolated source for the loader, preventing the `default` component from being included in loader-specific bundles.

```js
export function loader(ctx) {
  return {
    loader: '111'
  };
}
```

--------------------------------

### Solution 2: Loader Re-export Case 3 - Source

Source: https://github.com/shuvijs/shuvi/blob/main/test/fixtures/loader-tree-shaking/README.md

This is the source code for Case 3, where `loader` is defined as a constant assigned to an imported variable `a`. This pattern represents another limitation where SWC cannot apply the necessary transformations.

```js
Import { a } from './xx'
export const loader = a
```

=== COMPLETE CONTENT === This response contains all available snippets from this library. No additional content exists. Do not make further requests.