Corelib discovery and packaging

Platform spec feature

Corelib discovery and packaging

Back to Compiler integration ◎ Open in platform map

Spec standingStandard

Owner

Piotr Mikstacki pmikstacki@cybernomad.it

Submitter

Piotr Mikstacki pmikstacki@cybernomad.it

Current document

ADRs (4)

1. 0001-canonical-corelib-identity Canonical corelib package identity Accepted

   Published and resolved identity is corelib, not ad-hoc forks.

   Context

   Registry, CLI, and analysis must agree on one package name.

   Decision

   Rule	Detail
   Identity	Package name corelib; sources under beskid_corelib
   Legacy	standard_library paths may alias; identity remains corelib

   Consequences

   pckg publish, resolver, and docs use the same identity string.

   Verification anchors

   resolver.rs; beskid_tests corelib project fixtures.

   Open full ADR page

2. 0002-multi-path-discovery Multi-path corelib discovery Accepted

   Env, repo walk, and bundled CLI materialize the same tree.

   Context

   Developers run from superrepo, installed CLI, or CI without divergent roots.

   Decision

   Rule	Detail
   BESKID_CORELIB_ROOT	Points at root containing beskid_corelib/Project.proj
   Walk	Ancestor search for compiler/corelib/beskid_corelib
   Bundle	beskid_cli ensure_corelib_ready materializes embedded tree

   Consequences

   Missing roots fail fast with resolver diagnostics.

   Verification anchors

   corelib_runtime.rs; resolver.rs tests.

   Open full ADR page

3. 0003-readme-packaging-for-pckg Readme packaging for pckg artifacts Accepted

   Pack copies declared readme into README.md for registry docs.

   Context

   Registry consumers expect root README.md in .bpk artifacts.

   Decision

   Rule	Detail
   Declare	Optional readme = "path.md" in Project.proj
   Default	readme.md at package root when present
   Pack	beskid pckg pack places resolved file as README.md

   Consequences

   pckg documentation ingest uses consistent entry filename.

   Verification anchors

   PackagePublishDocumentation.cs; pack integration tests.

   Open full ADR page

4. 0004-workspace-includes-console-shard Workspace includes console shard Accepted

   corelib_console is a workspace member depended on by beskid_corelib.

   Context

   Console/ANSI must ship with the aggregate package, not as an orphan.

   Decision

   Rule	Detail
   Workspace	compiler/corelib/Workspace.proj lists packages/console
   Aggregate	beskid_corelib depends on corelib_console

   Consequences

   Publish CI packs the full workspace graph for registry corelib.

   Verification anchors

   Workspace.proj; corelib CI publish job.

   Open full ADR page

Articles

• Contracts and edge cases Normative guarantees and known edge cases for `Corelib discovery and packaging`. article Standard
• Design model Conceptual model for `Corelib discovery and packaging` and its subsystem boundaries. article Standard
• Examples Practical examples that demonstrate `Corelib discovery and packaging` behavior. article Standard
• FAQ and troubleshooting Common questions and debugging guidance for `Corelib discovery and packaging`. article Standard
• Flow and algorithm End-to-end control flow for corelib discovery, materialization, and packaging. article Standard
• Verification and traceability How `Corelib discovery and packaging` requirements map to tests and implementation anchors. article Standard

History

0 revisions (git unavailable at build; counts may be empty)

Open full history on GitHub

No commits recorded for this path.

Completeness

OKfeature · 2 SpecSection(s) · 1 H2 heading(s)

Section id	Required	Found
what-this-feature-specifies	yes	yes
implementation-anchors	yes	yes

Full tree: run pnpm verify:platform-spec-layout (writes src/generated/platform-spec-layout-report.json).

Related spec docs

• Area
  Compiler integration

  Parent area

• Area
  Resolution and projects

  Project graph logic resolves and injects corelib

• Area
  Stability and API shape

  API stability expectations depend on canonical packaging

What this feature specifies

This feature explains how compiler and tooling always load the same canonical corelib package identity and files. It is organized into newcomer-friendly articles that move from model, to flow, to contracts, then practical verification and debugging guidance.

Implementation anchors

• Canonical package root compiler/corelib/beskid_corelib
• Canonical package identity corelib (Project.proj), with beskid_corelib as the repository directory name
• Corelib path discovery in compiler/crates/beskid_analysis/src/projects/graph/resolver.rs
• CLI embedding/install support in compiler/crates/beskid_cli/build.rs and compiler/crates/beskid_cli/src/corelib_runtime.rs
• Integration checks in compiler/crates/beskid_tests/src/projects/corelib

Decisions

No open decisions. Closed choices are normative ADRs under adr/ (D-CORE-COMP-0001 … D-CORE-COMP-0004); use the reader ADRs tab for expandable detail.

Articles

• Canonical corelib package identityPublished and resolved identity is corelib, not ad-hoc forks.
• Contracts and edge casesNormative guarantees and known edge cases for `Corelib discovery and packaging`.
• Design modelConceptual model for `Corelib discovery and packaging` and its subsystem boundaries.
• ExamplesPractical examples that demonstrate `Corelib discovery and packaging` behavior.
• FAQ and troubleshootingCommon questions and debugging guidance for `Corelib discovery and packaging`.
• Flow and algorithmEnd-to-end control flow for corelib discovery, materialization, and packaging.
• Verification and traceabilityHow `Corelib discovery and packaging` requirements map to tests and implementation anchors.