Module startup 

What yapi loads from chest manifests: the installed extensions, with the grants, event policy and module root each runs with, and the placed skills.

Structs

Closed

A canonical folder or file of an extension entry chest leaves out, which runs with no grant if something else loads it.

FilePolicies

The policies of extension files, so a policy applies whichever source of the same file loads it.

Installed

What the installed entries of chest manifests give yapi.

LeftOut

The copies a run leaves out of each npm or git package that several sources install, so it loads once, from the first of: the project’s manifest, the project’s settings packages, the global manifest and the global settings packages. Of two entries of one manifest, the first loads. pi’s own rules decide between two settings copies.

Loaded

What chest gives one run of yapi, with the problems to show by manifest path: warnings and notices of the startup sync, entries left out, and manifests that fail to load.

Policy

What an extension runs with: its grants, its pi.events policy, and the folder it loads modules from without file access. It has no default, so every file says which one it gets.

Functions

duplicates

The warnings, by manifest path, for each copy of a package that a run leaves out because another source installs it too, as LeftOut decides. Their yapi remove -l commands take --approve unless the project of settings is trusted without it, by the decisions in agent_dir or the global defaultProjectTrust.

entry_label

How messages name the chest entry that gives an extension file the resolver reports with source and scope: extensions.<name> in <manifest>, the manifest named as chest’s own messages name it. None for a file chest doesn’t give.

file_policies

The policy of each extension file the resolver gave a chest: source in resolved, loaded or shadowed, from its package’s entry in installed, with the entries installed left out. A file that several entries give gets what all of them allow, and when that is less than one of them allows, adds a line to problems that names the entries, as found for the project in project_root. So does a file that an entry left out holds too, which runs with no grant. A chest file whose package has no entry runs with no grant and the isolated event policy, and adds a line to problems under its source.

installed

What chest gives a run in project_root, as load would, without installing anything: for yapi config, which shows what a run loads.

installed_inputs

The extensions and skills project has installed, locked and up to date, or patched, for a run in project_root: a stale or unlocked entry gives nothing until chest install. Entries left out for a reason the user should see add a line to problems.

load

What chest gives a run of yapi in project_root: the project manifest, only when trusted, and the user’s global one, only when global, each when it installs anything. Each puts back what its lock pins and is missing, unless offline, and skips stale or unlocked entries with a warning. It never writes a lock or .gitignore.

needs_trust

Whether the project manifest of project_root installs anything, so it needs the project’s trust as other project files that run code do. One with only [package], which describes the project as a package, does not. A manifest that does not parse needs trust too.

package_identity

The package that npm or git extension entry entry installs, as LeftOut compares copies: npm:<name> or git:<host>/<path>, as settings packages are matched. An entry with path takes one folder of it, which #<path> names, without . or empty segments.

project_manifest

The project manifest of project_root: the file MANIFEST_ENV names relative to it, else chest.toml. None when the variable names a file outside the project, as chest refuses it too. Its lock is the file beside it named with .lock.

reads_global

Whether a run reads the user’s global manifest: always, except in a project-only run whose projectOnly setting in settings can keep none of its entries, so nothing global is put back for nothing.

same_package

Whether two package_identity values, or settings identities, name copies of one package: the same package and path, or the whole package and one folder of it. Two paths of one package are two packages.

Type Aliases

Policies

The policies of chest’s packages, by the scope and source the resolver gives their files, such as ("project", "chest:todo"). installed_inputs builds the packages and their policies in one place, so they always match.