prjct-cli 0.35.2 → 0.35.3

package/packages/shared/node_modules/@types/bun/node_modules/bun-types/docs/pm/workspaces.mdx

@@ -1,115 +0,0 @@
----
-title: "Workspaces"
-description: "Develop complex monorepos with multiple independent packages"
----
-
-Bun supports [`workspaces`](https://docs.npmjs.com/cli/v9/using-npm/workspaces?v=true#description) in `package.json`. Workspaces make it easy to develop complex software as a _monorepo_ consisting of several independent packages.
-
-It's common for a monorepo to have the following structure:
-
-```txt File Tree icon="folder-tree"
-<root>
-├── README.md
-├── bun.lock
-├── package.json
-├── tsconfig.json
-└── packages
-    ├── pkg-a
-    │   ├── index.ts
-    │   ├── package.json
-    │   └── tsconfig.json
-    ├── pkg-b
-    │   ├── index.ts
-    │   ├── package.json
-    │   └── tsconfig.json
-    └── pkg-c
-        ├── index.ts
-        ├── package.json
-        └── tsconfig.json
-```
-
-In the root `package.json`, the `"workspaces"` key is used to indicate which subdirectories should be considered packages/workspaces within the monorepo. It's conventional to place all the workspace in a directory called `packages`.
-
-```json package.json icon="file-json"
-{
-  "name": "my-project",
-  "version": "1.0.0",
-  "workspaces": ["packages/*"],
-  "devDependencies": {
-    "example-package-in-monorepo": "workspace:*"
-  }
-}
-```
-
-<Note>
-  **Glob support** — Bun supports full glob syntax in `"workspaces"`, including negative patterns (e.g.
-  `!**/excluded/**`). See [here](/docs/runtime/glob#supported-glob-patterns) for a comprehensive list of supported syntax.
-</Note>
-
-```json package.json icon="file-json"
-{
-  "name": "my-project",
-  "version": "1.0.0",
-  "workspaces": ["packages/**", "!packages/**/test/**", "!packages/**/template/**"]
-}
-```
-
-Each workspace has it's own `package.json`. When referencing other packages in the monorepo, semver or workspace protocols (e.g. `workspace:*`) can be used as the version field in your `package.json`.
-
-```json packages/pkg-a/package.json icon="file-json"
-{
-  "name": "pkg-a",
-  "version": "1.0.0",
-  "dependencies": {
-    "pkg-b": "workspace:*"
-  }
-}
-```
-
-`bun install` will install dependencies for all workspaces in the monorepo, de-duplicating packages if possible. If you only want to install dependencies for specific workspaces, you can use the `--filter` flag.
-
-```bash
-# Install dependencies for all workspaces starting with `pkg-` except for `pkg-c`
-bun install --filter "pkg-*" --filter "!pkg-c"
-
-# Paths can also be used. This is equivalent to the command above.
-bun install --filter "./packages/pkg-*" --filter "!pkg-c" # or --filter "!./packages/pkg-c"
-```
-
-When publishing, `workspace:` versions are replaced by the package's `package.json` version,
-
-```
-"workspace:*" -> "1.0.1"
-"workspace:^" -> "^1.0.1"
-"workspace:~" -> "~1.0.1"
-```
-
-Setting a specific version takes precedence over the package's `package.json` version,
-
-```
-"workspace:1.0.2" -> "1.0.2" // Even if current version is 1.0.1
-```
-
-Workspaces have a couple major benefits.
-
-- **Code can be split into logical parts.** If one package relies on another, you can simply add it as a dependency in `package.json`. If package `b` depends on `a`, `bun install` will install your local `packages/a` directory into `node_modules` instead of downloading it from the npm registry.
-- **Dependencies can be de-duplicated.** If `a` and `b` share a common dependency, it will be _hoisted_ to the root `node_modules` directory. This reduces redundant disk usage and minimizes "dependency hell" issues associated with having multiple versions of a package installed simultaneously.
-- **Run scripts in multiple packages.** You can use the [`--filter` flag](/docs/pm/filter) to easily run `package.json` scripts in multiple packages in your workspace, , or `--workspaces` to run scripts across all workspaces.
-
-## Share versions with Catalogs
-
-When many packages need the same dependency versions, catalogs let you define
-those versions once in the root `package.json` and reference them from your
-workspaces using the `catalog:` protocol. Updating the catalog automatically
-updates every package that references it. See
-[Catalogs](/docs/pm/catalogs) for details.
-
-<Note>
-⚡️ **Speed** — Installs are fast, even for big monorepos. Bun installs the [Remix](https://github.com/remix-run/remix) monorepo in about `500ms` on Linux.
-
-- 28x faster than `npm install`
-- 12x faster than `yarn install` (v1)
-- 8x faster than `pnpm install`
-
-<Image src="https://user-images.githubusercontent.com/709451/212829600-77df9544-7c9f-4d8d-a984-b2cd0fd2aa52.png" />
-</Note>

package/packages/shared/node_modules/@types/bun/node_modules/bun-types/docs/project/benchmarking.mdx

@@ -1,241 +0,0 @@
----
-title: Benchmarking
-description: How to benchmark Bun
----
-
-Bun is designed for speed. Hot paths are extensively profiled and benchmarked. The source code for all of Bun's public benchmarks can be found in the [`/bench`](https://github.com/oven-sh/bun/tree/main/bench) directory of the Bun repo.
-
-## Measuring time
-
-To precisely measure time, Bun offers two runtime APIs functions:
-
-1. The Web-standard [`performance.now()`](https://developer.mozilla.org/en-US/docs/Web/API/Performance/now) function
-2. `Bun.nanoseconds()` which is similar to `performance.now()` except it returns the current time since the application started in nanoseconds. You can use `performance.timeOrigin` to convert this to a Unix timestamp.
-
-## Benchmarking tools
-
-When writing your own benchmarks, it's important to choose the right tool.
-
-- For microbenchmarks, a great general-purpose tool is [`mitata`](https://github.com/evanwashere/mitata).
-- For load testing, you _must use_ an HTTP benchmarking tool that is at least as fast as `Bun.serve()`, or your results will be skewed. Some popular Node.js-based benchmarking tools like [`autocannon`](https://github.com/mcollina/autocannon) are not fast enough. We recommend one of the following:
-  - [`bombardier`](https://github.com/codesenberg/bombardier)
-  - [`oha`](https://github.com/hatoo/oha)
-  - [`http_load_test`](https://github.com/uNetworking/uSockets/blob/master/examples/http_load_test.c)
-- For benchmarking scripts or CLI commands, we recommend [`hyperfine`](https://github.com/sharkdp/hyperfine).
-
-## Measuring memory usage
-
-Bun has two heaps. One heap is for the JavaScript runtime and the other heap is for everything else.
-
-### JavaScript heap stats
-
-The `bun:jsc` module exposes a few functions for measuring memory usage:
-
-```ts
-import { heapStats } from "bun:jsc";
-console.log(heapStats());
-```
-
-<Accordion title="View example statistics">
-
-```ts expandable icon="/icons/typescript.svg"
-{
-  heapSize: 1657575,
-  heapCapacity: 2872775,
-  extraMemorySize: 598199,
-  objectCount: 13790,
-  protectedObjectCount: 62,
-  globalObjectCount: 1,
-  protectedGlobalObjectCount: 1,
-  // A count of every object type in the heap
-  objectTypeCounts: {
-    CallbackObject: 25,
-    FunctionExecutable: 2078,
-    AsyncGeneratorFunction: 2,
-    'RegExp String Iterator': 1,
-    FunctionCodeBlock: 188,
-    ModuleProgramExecutable: 13,
-    String: 1,
-    UnlinkedModuleProgramCodeBlock: 13,
-    JSON: 1,
-    AsyncGenerator: 1,
-    Symbol: 1,
-    GetterSetter: 68,
-    ImportMeta: 10,
-    DOMAttributeGetterSetter: 1,
-    UnlinkedFunctionCodeBlock: 174,
-    RegExp: 52,
-    ModuleLoader: 1,
-    Intl: 1,
-    WeakMap: 4,
-    Generator: 2,
-    PropertyTable: 95,
-    'Array Iterator': 1,
-    JSLexicalEnvironment: 75,
-    UnlinkedFunctionExecutable: 2067,
-    WeakSet: 1,
-    console: 1,
-    Map: 23,
-    SparseArrayValueMap: 14,
-    StructureChain: 19,
-    Set: 18,
-    'String Iterator': 1,
-    FunctionRareData: 3,
-    JSGlobalLexicalEnvironment: 1,
-    Object: 481,
-    BigInt: 2,
-    StructureRareData: 55,
-    Array: 179,
-    AbortController: 2,
-    ModuleNamespaceObject: 11,
-    ShadowRealm: 1,
-    'Immutable Butterfly': 103,
-    Primordials: 1,
-    'Set Iterator': 1,
-    JSGlobalProxy: 1,
-    AsyncFromSyncIterator: 1,
-    ModuleRecord: 13,
-    FinalizationRegistry: 1,
-    AsyncIterator: 1,
-    InternalPromise: 22,
-    Iterator: 1,
-    CustomGetterSetter: 65,
-    Promise: 19,
-    WeakRef: 1,
-    InternalPromisePrototype: 1,
-    Function: 2381,
-    AsyncFunction: 2,
-    GlobalObject: 1,
-    ArrayBuffer: 2,
-    Boolean: 1,
-    Math: 1,
-    CallbackConstructor: 1,
-    Error: 2,
-    JSModuleEnvironment: 13,
-    WebAssembly: 1,
-    HashMapBucket: 300,
-    Callee: 3,
-    symbol: 37,
-    string: 2484,
-    Performance: 1,
-    ModuleProgramCodeBlock: 12,
-    JSSourceCode: 13,
-    JSPropertyNameEnumerator: 3,
-    NativeExecutable: 290,
-    Number: 1,
-    Structure: 1550,
-    SymbolTable: 108,
-    GeneratorFunction: 2,
-    'Map Iterator': 1
-  },
-  protectedObjectTypeCounts: {
-    CallbackConstructor: 1,
-    BigInt: 1,
-    RegExp: 2,
-    GlobalObject: 1,
-    UnlinkedModuleProgramCodeBlock: 13,
-    HashMapBucket: 2,
-    Structure: 41,
-    JSPropertyNameEnumerator: 1
-  }
-}
-```
-
-</Accordion>
-
-JavaScript is a garbage-collected language, not reference counted. It's normal and correct for objects to not be freed immediately in all cases, though it's not normal for objects to never be freed.
-
-To force garbage collection to run manually:
-
-```ts
-Bun.gc(true); // synchronous
-Bun.gc(false); // asynchronous
-```
-
-Heap snapshots let you inspect what objects are not being freed. You can use the `bun:jsc` module to take a heap snapshot and then view it with Safari or WebKit GTK developer tools. To generate a heap snapshot:
-
-```ts
-import { generateHeapSnapshot } from "bun";
-
-const snapshot = generateHeapSnapshot();
-await Bun.write("heap.json", JSON.stringify(snapshot, null, 2));
-```
-
-To view the snapshot, open the `heap.json` file in Safari's Developer Tools (or WebKit GTK)
-
-1. Open the Developer Tools
-2. Click "Timeline"
-3. Click "JavaScript Allocations" in the menu on the left. It might not be visible until you click the pencil icon to show all the timelines
-4. Click "Import" and select your heap snapshot JSON
-
-<Frame>
-  <img
-    src="https://user-images.githubusercontent.com/709451/204428943-ba999e8f-8984-4f23-97cb-b4e3e280363e.png"
-    alt="Importing a heap snapshot"
-  />
-</Frame>
-
-Once imported, you should see something like this:
-
-<Frame>
-  <img
-    alt="Viewing heap snapshot in Safari"
-    src="https://user-images.githubusercontent.com/709451/204429337-b0d8935f-3509-4071-b991-217794d1fb27.png"
-    caption="Viewing heap snapshot in Safari Dev Tools"
-  />
-</Frame>
-
-> The [web debugger](/docs/runtime/debugger#inspect) also offers the timeline feature which allows you to track and examine the memory usage of the running debug session.
-
-### Native heap stats
-
-Bun uses mimalloc for the other heap. To report a summary of non-JavaScript memory usage, set the `MIMALLOC_SHOW_STATS=1` environment variable. and stats will print on exit.
-
-```sh terminal icon="terminal"
-MIMALLOC_SHOW_STATS=1 bun script.js
-```
-
-```txt
-heap stats:    peak      total      freed    current       unit      count
-  reserved:   64.0 MiB   64.0 MiB      0       64.0 MiB                        not all freed!
- committed:   64.0 MiB   64.0 MiB      0       64.0 MiB                        not all freed!
-     reset:      0          0          0          0                            ok
-   touched:  128.5 KiB  128.5 KiB    5.4 MiB   -5.3 MiB                        ok
-  segments:      1          1          0          1                            not all freed!
--abandoned:      0          0          0          0                            ok
-   -cached:      0          0          0          0                            ok
-     pages:      0          0         53        -53                            ok
--abandoned:      0          0          0          0                            ok
- -extended:      0
- -noretire:      0
-     mmaps:      0
-   commits:      0
-   threads:      0          0          0          0                            ok
-  searches:     0.0 avg
-numa nodes:       1
-   elapsed:       0.068 s
-   process: user: 0.061 s, system: 0.014 s, faults: 0, rss: 57.4 MiB, commit: 64.0 MiB
-```
-
-## CPU profiling
-
-Profile JavaScript execution to identify performance bottlenecks with the `--cpu-prof` flag.
-
-```sh terminal icon="terminal"
-bun --cpu-prof script.js
-```
-
-This generates a `.cpuprofile` file you can open in Chrome DevTools (Performance tab → Load profile) or VS Code's CPU profiler.
-
-### Options
-
-```sh terminal icon="terminal"
-bun --cpu-prof --cpu-prof-name my-profile.cpuprofile script.js
-bun --cpu-prof --cpu-prof-dir ./profiles script.js
-```
-
-| Flag                         | Description          |
-| ---------------------------- | -------------------- |
-| `--cpu-prof`                 | Enable profiling     |
-| `--cpu-prof-name <filename>` | Set output filename  |
-| `--cpu-prof-dir <dir>`       | Set output directory |

package/packages/shared/node_modules/@types/bun/node_modules/bun-types/docs/project/bindgen.mdx

@@ -1,223 +0,0 @@
----
-title: Bindgen
-description: Bindgen for Bun
----
-
-<Note>This document is for maintainers and contributors to Bun, and describes internal implementation details.</Note>
-
-The new bindings generator, introduced to the codebase in Dec 2024, scans for
-`*.bind.ts` to find function and class definition, and generates glue code to
-interop between JavaScript and native code.
-
-There are currently other code generators and systems that achieve similar
-purposes. The following will all eventually be completely phased out in favor of
-this one:
-
-- "Classes generator", converting `*.classes.ts` for custom classes.
-- "JS2Native", allowing ad-hoc calls from `src/js` to native code.
-
-## Creating JS Functions in Zig
-
-Given a file implementing a simple function, such as `add`
-
-```zig src/bun.js/math.zig
-pub fn add(global: *jsc.JSGlobalObject, a: i32, b: i32) !i32 {
-    return std.math.add(i32, a, b) catch {
-        // Binding functions can return `error.OutOfMemory` and `error.JSError`.
-        // Others like `error.Overflow` from `std.math.add` must be converted.
-        // Remember to be descriptive.
-        return global.throwPretty("Integer overflow while adding", .{});
-    };
-}
-
-const gen = bun.gen.math; // "math" being this file's basename
-
-const std = @import("std");
-const bun = @import("bun");
-const jsc = bun.jsc;
-```
-
-Then describe the API schema using a `.bind.ts` function. The binding file goes next to the Zig file.
-
-```ts src/bun.js/math.bind.ts icon="/icons/typescript.svg"
-import { t, fn } from "bindgen";
-
-export const add = fn({
-  args: {
-    global: t.globalObject,
-    a: t.i32,
-    b: t.i32.default(1),
-  },
-  ret: t.i32,
-});
-```
-
-This function declaration is equivalent to:
-
-```ts
-/**
- * Throws if zero arguments are provided.
- * Wraps out of range numbers using modulo.
- */
-declare function add(a: number, b: number = 1): number;
-```
-
-The code generator will provide `bun.gen.math.jsAdd`, which is the native
-function implementation. To pass to JavaScript, use
-`bun.gen.math.createAddCallback(global)`. JS files in `src/js/` may use
-`$bindgenFn("math.bind.ts", "add")` to get a handle to the implementation.
-
-## Strings
-
-The type for receiving strings is one of [`t.DOMString`](https://webidl.spec.whatwg.org/#idl-DOMString), [`t.ByteString`](https://webidl.spec.whatwg.org/#idl-ByteString), and [`t.USVString`](https://webidl.spec.whatwg.org/#idl-USVString). These map directly to their WebIDL counterparts, and have slightly different conversion logic. Bindgen will pass BunString to native code in all cases.
-
-When in doubt, use DOMString.
-
-`t.UTF8String` can be used in place of `t.DOMString`, but will call `bun.String.toUTF8`. The native callback gets `[]const u8` (WTF-8 data) passed to native code, freeing it after the function returns.
-
-TLDRs from WebIDL spec:
-
-- ByteString can only contain valid latin1 characters. It is not safe to assume bun.String is already in 8-bit format, but it is extremely likely.
-- USVString will not contain invalid surrogate pairs, aka text that can be represented correctly in UTF-8.
-- DOMString is the loosest but also most recommended strategy.
-
-## Function Variants
-
-A `variants` can specify multiple variants (also known as overloads).
-
-```ts src/bun.js/math.bind.ts icon="/icons/typescript.svg"
-import { t, fn } from "bindgen";
-
-export const action = fn({
-  variants: [
-    {
-      args: {
-        a: t.i32,
-      },
-      ret: t.i32,
-    },
-    {
-      args: {
-        a: t.DOMString,
-      },
-      ret: t.DOMString,
-    },
-  ],
-});
-```
-
-In Zig, each variant gets a number, based on the order the schema defines.
-
-```zig
-fn action1(a: i32) i32 {
-  return a;
-}
-
-fn action2(a: bun.String) bun.String {
-  return a;
-}
-```
-
-## `t.dictionary`
-
-A `dictionary` is a definition for a JavaScript object, typically as a function inputs. For function outputs, it is usually a smarter idea to declare a class type to add functions and destructuring.
-
-## Enumerations
-
-To use [WebIDL's enumeration](https://webidl.spec.whatwg.org/#idl-enums) type, use either:
-
-- `t.stringEnum`: Create and codegen a new enum type.
-- `t.zigEnum`: Derive a bindgen type off of an existing enum in the codebase.
-
-An example of `stringEnum` as used in `fmt.zig` / `bun:internal-for-testing`
-
-```ts
-export const Formatter = t.stringEnum("highlight-javascript", "escape-powershell");
-
-export const fmtString = fn({
-  args: {
-    global: t.globalObject,
-    code: t.UTF8String,
-    formatter: Formatter,
-  },
-  ret: t.DOMString,
-});
-```
-
-WebIDL strongly encourages using kebab case for enumeration values, to be consistent with existing Web APIs.
-
-### Deriving enums from Zig code
-
-TODO: zigEnum
-
-## `t.oneOf`
-
-A `oneOf` is a union between two or more types. It is represented by `union(enum)` in Zig.
-
-TODO:
-
-## Attributes
-
-There are set of attributes that can be chained onto `t.*` types. On all types there are:
-
-- `.required`, in dictionary parameters only
-- `.optional`, in function arguments only
-- `.default(T)`
-
-When a value is optional, it is lowered to a Zig optional.
-
-Depending on the type, there are more attributes available. See the type definitions in auto-complete for more details. Note that one of the above three can only be applied, and they must be applied at the end.
-
-### Integer Attributes
-
-Integer types allow customizing the overflow behavior with `clamp` or `enforceRange`
-
-```ts
-import { t, fn } from "bindgen";
-
-export const add = fn({
-  args: {
-    global: t.globalObject,
-    // enforce in i32 range
-    a: t.i32.enforceRange(),
-    // clamp to u16 range
-    b: t.u16,
-    // enforce in arbitrary range, with a default if not provided
-    c: t.i32.enforceRange(0, 1000).default(5),
-    // clamp to arbitrary range, or null
-    d: t.u16.clamp(0, 10).optional,
-  },
-  ret: t.i32,
-});
-```
-
-Various Node.js validator functions such as `validateInteger`, `validateNumber`, and more are available. Use these when implementing Node.js APIs, so the error messages match 1:1 what Node would do.
-
-Unlike `enforceRange`, which is taken from WebIDL, `validate*` functions are much more strict on the input they accept. For example, Node's numerical validator check `typeof value === 'number'`, while WebIDL uses `ToNumber` for lossy conversion.
-
-```ts
-import { t, fn } from "bindgen";
-
-export const add = fn({
-  args: {
-    global: t.globalObject,
-    // throw if not given a number
-    a: t.f64.validateNumber(),
-    // valid in i32 range
-    a: t.i32.validateInt32(),
-    // f64 within safe integer range
-    b: t.f64.validateInteger(),
-    // f64 in given range
-    c: t.f64.validateNumber(-10000, 10000),
-  },
-  ret: t.i32,
-});
-```
-
-## Callbacks
-
-TODO
-
-## Classes
-
-TODO