Using packages
partly builtMissing: the public registry, so a package is added from a folder or a git tag, never by name. See What is built.
The kinds of package, where they come from, and what a package may do in your app.
| Kinds of package A package is Jadpo code shared between apps. |
| Where packages live
|
| Where packages come from partly A package reaches your app in one of four ways. |
| A package's surface A package's surface is everything it offers an app, in one file you can read. |
| What package code may do A provider package may act on its own API, but never on your app's data. |
| What reviewers see The approval report (Reviewing a change) lists, for each change. |
| What a provider description costs your build A provider's description doesn't slow your build, however large it is, because the compiler never reads it. |
| Enum values and failures through a package How your app writes a package's enum values and failures: through the package's name, as its types are. |
Details
The exact rules, for when you hit an edge case.
| How packages are installed and linked This is the detail behind Installing safely: what |
| A package's names, and watching a linked checkout How a name written through a package is told apart from the app's own, and how |
| Two versions side by side, lazy loading and the package cache How an app holds two major versions of one package while it moves between them, and how Jadpo avoids compiling and checking package code the app doesn't use. |
| How the OpenAPI importer reads a document What |
| Shape and name detection How the importer turns a provider's fields into standard types, by their shape and their names. |
| The scoped review and unconfirmed operations This is the detail behind layers 4 and 5 of Mapping imported types to standard types: which imported types you review, how a review is marked, and which calls still need a recording to confirm them. |
Markdown for agents: /docs/using-packages.md.Built from Jadpo main at aee2e8f.