npm - @hasna/skills - Versions diffs - 0.1.22 → 0.1.23 - Mend

@hasna/skills 0.1.22 → 0.1.23

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

Files changed (699) hide show

package/skills/skill-logo-design/node_modules/bun-types/docs/pm/isolated-installs.mdx DELETED Viewed

@@ -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 should be straightforward:
-```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/skills/skill-logo-design/node_modules/bun-types/docs/pm/lifecycle.mdx DELETED Viewed

@@ -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/skills/skill-logo-design/node_modules/bun-types/docs/pm/lockfile.mdx DELETED Viewed

@@ -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/skills/skill-logo-design/node_modules/bun-types/docs/pm/npmrc.mdx DELETED Viewed

@@ -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/skills/skill-logo-design/node_modules/bun-types/docs/pm/overrides.mdx DELETED Viewed

@@ -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 ++]
-}
-```