@hasna/connectors 1.3.31 → 1.3.33

package/connectors/connect-imessage/node_modules/bun-types/docs/pm/isolated-installs.mdx

@@ -1,220 +0,0 @@
----
-title: "Isolated installs"
-description: "Strict dependency isolation similar to pnpm's approach"
----
-
-Bun provides an alternative package installation strategy called **isolated installs** that creates strict dependency isolation similar to pnpm's approach. This mode prevents phantom dependencies and ensures reproducible, deterministic builds.
-
-This is the default installation strategy for **new** workspace/monorepo projects (with `configVersion = 1` in the lockfile). Existing projects continue using hoisted installs unless explicitly configured.
-
-## What are isolated installs?
-
-Isolated installs create a non-hoisted dependency structure where packages can only access their explicitly declared dependencies. This differs from the traditional "hoisted" installation strategy used by npm and Yarn, where dependencies are flattened into a shared `node_modules` directory.
-
-### Key benefits
-
-- **Prevents phantom dependencies** — Packages cannot accidentally import dependencies they haven't declared
-- **Deterministic resolution** — Same dependency tree regardless of what else is installed
-- **Better for monorepos** — Workspace isolation prevents cross-contamination between packages
-- **Reproducible builds** — More predictable resolution behavior across environments
-
-## Using isolated installs
-
-### Command line
-
-Use the `--linker` flag to specify the installation strategy:
-
-```bash terminal icon="terminal"
-# Use isolated installs
-bun install --linker isolated
-
-# Use traditional hoisted installs
-bun install --linker hoisted
-```
-
-### Configuration file
-
-Set the default linker strategy in your `bunfig.toml` or globally in `$HOME/.bunfig.toml`:
-
-```toml bunfig.toml icon="settings"
-[install]
-linker = "isolated"
-```
-
-### Default behavior
-
-The default linker strategy depends on your project's lockfile `configVersion`:
-
-| `configVersion` | Using workspaces? | Default Linker |
-| --------------- | ----------------- | -------------- |
-| `1`             | ✅                | `isolated`     |
-| `1`             | ❌                | `hoisted`      |
-| `0`             | ✅                | `hoisted`      |
-| `0`             | ❌                | `hoisted`      |
-
-**New projects**: Default to `configVersion = 1`. In workspaces, v1 uses the isolated linker by default; otherwise it uses hoisted linking.
-
-**Existing Bun projects (made pre-v1.3.2)**: If your existing lockfile doesn't have a version yet, Bun sets `configVersion = 0` when you run `bun install`, preserving the previous hoisted linker default.
-
-**Migrations from other package managers**:
-
-- From pnpm: `configVersion = 1` (using isolated installs in workspaces)
-- From npm or yarn: `configVersion = 0` (using hoisted installs)
-
-You can override the default behavior by explicitly specifying the `--linker` flag or setting it in your configuration file.
-
-## How isolated installs work
-
-### Directory structure
-
-Instead of hoisting dependencies, isolated installs create a two-tier structure:
-
-```bash tree layout of node_modules icon="list-tree"
-node_modules/
-├── .bun/                          # Central package store
-│   ├── package@1.0.0/             # Versioned package installations
-│   │   └── node_modules/
-│   │       └── package/           # Actual package files
-│   ├── @scope+package@2.1.0/      # Scoped packages (+ replaces /)
-│   │   └── node_modules/
-│   │       └── @scope/
-│   │           └── package/
-│   └── ...
-└── package-name -> .bun/package@1.0.0/node_modules/package  # Symlinks
-```
-
-### Resolution algorithm
-
-1. **Central store** — All packages are installed in `node_modules/.bun/package@version/` directories
-2. **Symlinks** — Top-level `node_modules` contains symlinks pointing to the central store
-3. **Peer resolution** — Complex peer dependencies create specialized directory names
-4. **Deduplication** — Packages with identical package IDs and peer dependency sets are shared
-
-### Workspace handling
-
-In monorepos, workspace dependencies are handled specially:
-
-- **Workspace packages** — Symlinked directly to their source directories, not the store
-- **Workspace dependencies** — Can access other workspace packages in the monorepo
-- **External dependencies** — Installed in the isolated store with proper isolation
-
-## Comparison with hoisted installs
-
-| Aspect                    | Hoisted (npm/Yarn)                         | Isolated (pnpm-like)                    |
-| ------------------------- | ------------------------------------------ | --------------------------------------- |
-| **Dependency access**     | Packages can access any hoisted dependency | Packages only see declared dependencies |
-| **Phantom dependencies**  | ❌ Possible                                | ✅ Prevented                            |
-| **Disk usage**            | ✅ Lower (shared installs)                 | ✅ Similar (uses symlinks)              |
-| **Determinism**           | ❌ Less deterministic                      | ✅ More deterministic                   |
-| **Node.js compatibility** | ✅ Standard behavior                       | ✅ Compatible via symlinks              |
-| **Best for**              | Single projects, legacy code               | Monorepos, strict dependency management |
-
-## Advanced features
-
-### Peer dependency handling
-
-Isolated installs handle peer dependencies through sophisticated resolution:
-
-```bash tree layout of node_modules icon="list-tree"
-# Package with peer dependencies creates specialized paths
-node_modules/.bun/package@1.0.0_react@18.2.0/
-```
-
-The directory name encodes both the package version and its peer dependency versions, ensuring each unique combination gets its own installation.
-
-### Backend strategies
-
-Bun uses different file operation strategies for performance:
-
-- **Clonefile** (macOS) — Copy-on-write filesystem clones for maximum efficiency
-- **Hardlink** (Linux/Windows) — Hardlinks to save disk space
-- **Copyfile** (fallback) — Full file copies when other methods aren't available
-
-### Debugging isolated installs
-
-Enable verbose logging to understand the installation process:
-
-```bash terminal icon="terminal"
-bun install --linker isolated --verbose
-```
-
-This shows:
-
-- Store entry creation
-- Symlink operations
-- Peer dependency resolution
-- Deduplication decisions
-
-## Troubleshooting
-
-### Compatibility issues
-
-Some packages may not work correctly with isolated installs due to:
-
-- **Hardcoded paths** — Packages that assume a flat `node_modules` structure
-- **Dynamic imports** — Runtime imports that don't follow Node.js resolution
-- **Build tools** — Tools that scan `node_modules` directly
-
-If you encounter issues, you can:
-
-1. **Switch to hoisted mode** for specific projects:
-
-   ```bash terminal icon="terminal"
-   bun install --linker hoisted
-   ```
-
-2. **Report compatibility issues** to help improve isolated install support
-
-### Performance considerations
-
-- **Install time** — May be slightly slower due to symlink operations
-- **Disk usage** — Similar to hoisted (uses symlinks, not file copies)
-- **Memory usage** — Higher during install due to complex peer resolution
-
-## Migration guide
-
-### From npm/Yarn
-
-```bash terminal icon="terminal"
-# Remove existing node_modules and lockfiles
-rm -rf node_modules package-lock.json yarn.lock
-
-# Install with isolated linker
-bun install --linker isolated
-```
-
-### From pnpm
-
-Isolated installs are conceptually similar to pnpm, so migration is direct:
-
-```bash terminal icon="terminal"
-# Remove pnpm files
-rm -rf node_modules pnpm-lock.yaml
-
-# Install with Bun's isolated linker
-bun install --linker isolated
-```
-
-The main difference is that Bun uses symlinks in `node_modules` while pnpm uses a global store with symlinks.
-
-## When to use isolated installs
-
-**Use isolated installs when:**
-
-- Working in monorepos with multiple packages
-- Strict dependency management is required
-- Preventing phantom dependencies is important
-- Building libraries that need deterministic dependencies
-
-**Use hoisted installs when:**
-
-- Working with legacy code that assumes flat `node_modules`
-- Compatibility with existing build tools is required
-- Working in environments where symlinks aren't well supported
-- You prefer the simpler traditional npm behavior
-
-## Related documentation
-
-- [Package manager > Workspaces](/docs/pm/workspaces) — Monorepo workspace management
-- [Package manager > Lockfile](/docs/pm/lockfile) — Understanding Bun's lockfile format
-- [CLI > install](/docs/pm/cli/install) — Complete `bun install` command reference

package/connectors/connect-imessage/node_modules/bun-types/docs/pm/lifecycle.mdx

@@ -1,64 +0,0 @@
----
-title: "Lifecycle scripts"
-description: "How Bun handles package lifecycle scripts securely"
----
-
-Packages on `npm` can define _lifecycle scripts_ in their `package.json`. Some of the most common are below, but there are [many others](https://docs.npmjs.com/cli/v10/using-npm/scripts).
-
-- `preinstall`: Runs before the package is installed
-- `postinstall`: Runs after the package is installed
-- `preuninstall`: Runs before the package is uninstalled
-- `prepublishOnly`: Runs before the package is published
-
-These scripts are arbitrary shell commands that the package manager is expected to read and execute at the appropriate time. But executing arbitrary scripts represents a potential security risk, so—unlike other `npm` clients—Bun does not execute arbitrary lifecycle scripts by default.
-
----
-
-## `postinstall`
-
-The `postinstall` script is particularly important. It's widely used to build or install platform-specific binaries for packages that are implemented as [native Node.js add-ons](https://nodejs.org/api/addons.html). For example, `node-sass` is a popular package that uses `postinstall` to build a native binary for Sass.
-
-```json package.json icon="file-json"
-{
-  "name": "my-app",
-  "version": "1.0.0",
-  "dependencies": {
-    "node-sass": "^6.0.1"
-  }
-}
-```
-
----
-
-## `trustedDependencies`
-
-Instead of executing arbitrary scripts, Bun uses a "default-secure" approach. You can add certain packages to an allow list, and Bun will execute lifecycle scripts for those packages. To tell Bun to allow lifecycle scripts for a particular package, add the package name to `trustedDependencies` array in your `package.json`.
-
-```json package.json icon="file-json"
-{
-  "name": "my-app",
-  "version": "1.0.0",
-  "trustedDependencies": ["node-sass"] // [!code ++]
-}
-```
-
-Once added to `trustedDependencies`, install/re-install the package. Bun will read this field and run lifecycle scripts for `my-trusted-package`.
-
-The top 500 npm packages with lifecycle scripts are allowed by default. You can see the full list [here](https://github.com/oven-sh/bun/blob/main/src/install/default-trusted-dependencies.txt).
-
-<Note>
-  The default trusted dependencies list only applies to packages installed from npm. For packages from other sources
-  (such as `file:`, `link:`, `git:`, or `github:` dependencies), you must explicitly add them to `trustedDependencies`
-  to run their lifecycle scripts, even if the package name matches an entry in the default list. This prevents malicious
-  packages from spoofing trusted package names through local file paths or git repositories.
-</Note>
-
----
-
-## `--ignore-scripts`
-
-To disable lifecycle scripts for all packages, use the `--ignore-scripts` flag.
-
-```bash terminal icon="terminal"
-bun install --ignore-scripts
-```

package/connectors/connect-imessage/node_modules/bun-types/docs/pm/lockfile.mdx

@@ -1,64 +0,0 @@
----
-title: "Lockfile"
-description: "Bun's lockfile format and configuration"
----
-
-Running `bun install` will create a lockfile called `bun.lock`.
-
-#### Should it be committed to git?
-
-Yes
-
-#### Generate a lockfile without installing?
-
-To generate a lockfile without installing to `node_modules` you can use the `--lockfile-only` flag. The lockfile will always be saved to disk, even if it is up-to-date with the `package.json`(s) for your project.
-
-```bash terminal icon="terminal"
-bun install --lockfile-only
-```
-
-<Note>
-  Using `--lockfile-only` will still populate the global install cache with registry metadata and git/tarball
-  dependencies.
-</Note>
-
-#### Can I opt out?
-
-To install without creating a lockfile:
-
-```bash terminal icon="terminal"
-bun install --no-save
-```
-
-To install a Yarn lockfile _in addition_ to `bun.lock`.
-
-<CodeGroup>
-
-```bash terminal icon="terminal"
-bun install --yarn
-```
-
-```toml bunfig.toml icon="settings"
-[install.lockfile]
-# whether to save a non-Bun lockfile alongside bun.lock
-# only "yarn" is supported
-print = "yarn"
-```
-
-</CodeGroup>
-
-#### Text-based lockfile
-
-Bun v1.2 changed the default lockfile format to the text-based `bun.lock`. Existing binary `bun.lockb` lockfiles can be migrated to the new format by running `bun install --save-text-lockfile --frozen-lockfile --lockfile-only` and deleting `bun.lockb`.
-
-More information about the new lockfile format can be found on [our blogpost](https://bun.com/blog/bun-lock-text-lockfile).
-
-#### Automatic lockfile migration
-
-When running `bun install` in a project without a `bun.lock`, Bun automatically migrates existing lockfiles:
-
-- `yarn.lock` (v1)
-- `package-lock.json` (npm)
-- `pnpm-lock.yaml` (pnpm)
-
-The original lockfile is preserved and can be removed manually after verification.

package/connectors/connect-imessage/node_modules/bun-types/docs/pm/npmrc.mdx

@@ -1,245 +0,0 @@
----
-title: .npmrc support
-description:
----
-
-Bun supports loading configuration options from [`.npmrc`](https://docs.npmjs.com/cli/v10/configuring-npm/npmrc) files, allowing you to reuse existing registry/scope configurations.
-
-<Note>
-  We recommend migrating your `.npmrc` file to Bun's [`bunfig.toml`](/docs/runtime/bunfig) format, as it provides more
-  flexible options and can let you configure Bun-specific options.
-</Note>
-
----
-
-## Supported options
-
-### Set the default registry
-
-The default registry is used to resolve packages, its default value is `npm`'s official registry (`https://registry.npmjs.org/`).
-
-To change it, you can set the `registry` option in `.npmrc`:
-
-```ini .npmrc icon="npm"
-registry=http://localhost:4873/
-```
-
-The equivalent `bunfig.toml` option is [`install.registry`](/docs/runtime/bunfig#install-registry):
-
-```toml bunfig.toml icon="settings"
-install.registry = "http://localhost:4873/"
-```
-
-### Set the registry for a specific scope
-
-`@<scope>:registry` allows you to set the registry for a specific scope:
-
-```ini .npmrc icon="npm"
-@myorg:registry=http://localhost:4873/
-```
-
-The equivalent `bunfig.toml` option is to add a key in [`install.scopes`](/docs/runtime/bunfig#install-registry):
-
-```toml bunfig.toml icon="settings"
-[install.scopes]
-myorg = "http://localhost:4873/"
-```
-
-### Configure options for a specific registry
-
-`//<registry_url>/:<key>=<value>` allows you to set options for a specific registry:
-
-```ini .npmrc icon="npm"
-# set an auth token for the registry
-# ${...} is a placeholder for environment variables
-//http://localhost:4873/:_authToken=${NPM_TOKEN}
-
-
-# or you could set a username and password
-# note that the password is base64 encoded
-//http://localhost:4873/:username=myusername
-
-//http://localhost:4873/:_password=${NPM_PASSWORD}
-
-# or use _auth, which is your username and password
-# combined into a single string, which is then base 64 encoded
-//http://localhost:4873/:_auth=${NPM_AUTH}
-```
-
-The following options are supported:
-
-- `_authToken`
-- `username`
-- `_password` (base64 encoded password)
-- `_auth` (base64 encoded username:password, e.g. `btoa(username + ":" + password)`)
-- `email`
-
-The equivalent `bunfig.toml` option is to add a key in [`install.scopes`](/docs/runtime/bunfig#install-registry):
-
-```toml bunfig.toml icon="settings"
-[install.scopes]
-myorg = { url = "http://localhost:4873/", username = "myusername", password = "$NPM_PASSWORD" }
-```
-
-### `link-workspace-packages`: Control workspace package installation
-
-Controls how workspace packages are installed when available locally:
-
-```ini .npmrc icon="npm"
-link-workspace-packages=true
-```
-
-The equivalent `bunfig.toml` option is [`install.linkWorkspacePackages`](/docs/runtime/bunfig#install-linkworkspacepackages):
-
-```toml bunfig.toml icon="settings"
-[install]
-linkWorkspacePackages = true
-```
-
-### `save-exact`: Save exact versions
-
-Always saves exact versions without the `^` prefix:
-
-```ini .npmrc icon="npm"
-save-exact=true
-```
-
-The equivalent `bunfig.toml` option is [`install.exact`](/docs/runtime/bunfig#install-exact):
-
-```toml bunfig.toml icon="settings"
-[install]
-exact = true
-```
-
-### `ignore-scripts`: Skip lifecycle scripts
-
-Prevents running lifecycle scripts during installation:
-
-```ini .npmrc icon="npm"
-ignore-scripts=true
-```
-
-This is equivalent to using the `--ignore-scripts` flag with `bun install`.
-
-### `dry-run`: Preview changes without installing
-
-Shows what would be installed without actually installing:
-
-```ini .npmrc icon="npm"
-dry-run=true
-```
-
-The equivalent `bunfig.toml` option is [`install.dryRun`](/docs/runtime/bunfig#install-dryrun):
-
-```toml bunfig.toml icon="settings"
-[install]
-dryRun = true
-```
-
-### `cache`: Configure cache directory
-
-Set the cache directory path, or disable caching:
-
-```ini .npmrc icon="npm"
-# set a custom cache directory
-cache=/path/to/cache
-
-# or disable caching
-cache=false
-```
-
-The equivalent `bunfig.toml` option is [`install.cache`](/docs/runtime/bunfig#install-cache):
-
-```toml bunfig.toml icon="settings"
-[install.cache]
-# set a custom cache directory
-dir = "/path/to/cache"
-
-# or disable caching
-disable = true
-```
-
-### `ca` and `cafile`: Configure CA certificates
-
-Configure custom CA certificates for registry connections:
-
-```ini .npmrc icon="npm"
-# single CA certificate
-ca="-----BEGIN CERTIFICATE-----\n...\n-----END CERTIFICATE-----"
-
-# multiple CA certificates
-ca[]="-----BEGIN CERTIFICATE-----\n...\n-----END CERTIFICATE-----"
-ca[]="-----BEGIN CERTIFICATE-----\n...\n-----END CERTIFICATE-----"
-
-# or specify a path to a CA file
-cafile=/path/to/ca-bundle.crt
-```
-
-### `omit` and `include`: Control dependency types
-
-Control which dependency types are installed:
-
-```ini .npmrc icon="npm"
-# omit dev dependencies
-omit=dev
-
-# omit multiple types
-omit[]=dev
-omit[]=optional
-
-# include specific types (overrides omit)
-include=dev
-```
-
-Valid values: `dev`, `peer`, `optional`
-
-### `install-strategy` and `node-linker`: Installation strategy
-
-Control how packages are installed in `node_modules`. Bun supports two different configuration options for compatibility with different package managers.
-
-**npm's `install-strategy`:**
-
-```ini .npmrc icon="npm"
-# flat node_modules structure (default)
-install-strategy=hoisted
-
-# symlinked structure
-install-strategy=linked
-```
-
-**pnpm/yarn's `node-linker`:**
-
-The `node-linker` option controls the installation mode. Bun supports values from both pnpm and yarn:
-
-| Value          | Description                                     | Accepted by |
-| -------------- | ----------------------------------------------- | ----------- |
-| `isolated`     | Symlinked structure with isolated dependencies  | pnpm        |
-| `hoisted`      | Flat node_modules structure                     | pnpm        |
-| `pnpm`         | Symlinked structure (same as `isolated`)        | yarn        |
-| `node-modules` | Flat node_modules structure (same as `hoisted`) | yarn        |
-
-```ini .npmrc icon="npm"
-# symlinked/isolated mode
-node-linker=isolated
-node-linker=pnpm
-
-# flat/hoisted mode
-node-linker=hoisted
-node-linker=node-modules
-```
-
-### `public-hoist-pattern` and `hoist-pattern`: Control hoisting
-
-Control which packages are hoisted to the root `node_modules`:
-
-```ini .npmrc icon="npm"
-# packages matching this pattern will be hoisted to the root
-public-hoist-pattern=*eslint*
-
-# multiple patterns
-public-hoist-pattern[]=*eslint*
-public-hoist-pattern[]=*prettier*
-
-# control general hoisting behavior
-hoist-pattern=*
-```

package/connectors/connect-imessage/node_modules/bun-types/docs/pm/overrides.mdx

@@ -1,83 +0,0 @@
----
-title: "Overrides and resolutions"
-description: "Control metadependency versions with npm overrides and Yarn resolutions"
----
-
-Bun supports npm's `"overrides"` and Yarn's `"resolutions"` in `package.json`. These are mechanisms for specifying a version range for _metadependencies_—the dependencies of your dependencies.
-
-{/* prettier-ignore */}
-```json package.json icon="file-json"
-{
-  "name": "my-app",
-  "dependencies": {
-    "foo": "^2.0.0"
-  },
-  "overrides": { // [!code ++]
-    "bar": "~4.4.0" // [!code ++]
-  } // [!code ++]
-}
-```
-
-By default, Bun will install the latest version of all dependencies and metadependencies, according to the ranges specified in each package's `package.json`. Let's say you have a project with one dependency, `foo`, which in turn has a dependency on `bar`. This means `bar` is a _metadependency_ of our project.
-
-```json package.json icon="file-json"
-{
-  "name": "my-app",
-  "dependencies": {
-    "foo": "^2.0.0"
-  }
-}
-```
-
-When you run `bun install`, Bun will install the latest versions of each package.
-
-```txt tree layout of node_modules icon="list-tree"
-node_modules
-├── foo@1.2.3
-└── bar@4.5.6
-```
-
-But what if a security vulnerability was introduced in `bar@4.5.6`? We may want a way to pin `bar` to an older version that doesn't have the vulnerability. This is where `"overrides"`/`"resolutions"` come in.
-
----
-
-## `"overrides"`
-
-Add `bar` to the `"overrides"` field in `package.json`. Bun will defer to the specified version range when determining which version of `bar` to install, whether it's a dependency or a metadependency.
-
-<Note>
-  Bun currently only supports top-level `"overrides"`. [Nested
-  overrides](https://docs.npmjs.com/cli/v9/configuring-npm/package-json#overrides) are not supported.
-</Note>
-
-{/* prettier-ignore */}
-```json package.json icon="file-json"
-{
-  "name": "my-app",
-  "dependencies": {
-    "foo": "^2.0.0"
-  },
-  "overrides": { // [!code ++]
-    "bar": "~4.4.0" // [!code ++]
-  } // [!code ++]
-}
-```
-
-## `"resolutions"`
-
-The syntax is similar for `"resolutions"`, which is Yarn's alternative to `"overrides"`. Bun supports this feature to make migration from Yarn easier.
-
-As with `"overrides"`, _nested resolutions_ are not currently supported.
-
-{/* prettier-ignore */}
-```json package.json icon="file-json"
-{
-  "name": "my-app",
-  "dependencies": {
-    "foo": "^2.0.0"
-  },
-  "resolutions": { // [!code ++]
-    "bar": "~4.4.0" // [!code ++]
-  } // [!code ++]
-}
-```