package-public-api

Enforces barrel-only public API exports for shared, domain, and features packages.

615|491|Updated Jan 4, 2022
One-click install
npx skills add https://github.com/LedgerHQ/ledger-live --skill package-public-api
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: package-public-api
Source: https://github.com/LedgerHQ/ledger-live/tree/main/.cursor/skills/package-public-api
Command: npx skills add https://github.com/LedgerHQ/ledger-live --skill package-public-api

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

New-architecture packages in the Ledger Live monorepo (shared/, domain/, features/) can accidentally leak internal implementation details through their index files, breaking encapsulation and causing lint:structure check failures.

Core Features & Use Cases

  • Barrel Enforcement: Ensures every package index file contains nothing but export * statements, keeping the public API surface explicit.
  • Internals Isolation: Directs private code into a dedicated internals location so it is never re-exported publicly.
  • Use Case: When creating a new package under shared/, domain/, or features/, or when a lint:structure check fails on an index.* file, follow this Skill to restructure exports so only intended modules are exposed.

Quick Start

Read the package-public-api skill and fix my features/mypackage/index.ts so it only re-exports the public API.

Frequently Asked Questions about package-public-api

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I structure a package public API with barrel files?

Create an index file at the package root containing only `export *` statements that re-export the intended public modules. Keep all private implementation code in an internals location that is never re-exported from the barrel.

Why does my lint:structure check fail on an index file?

The check fails when an index.* file contains anything other than `export *` statements, such as direct declarations, named re-export lists, or logic. Move that code into the package internals and re-export only through barrels.

Where should private code live in shared, domain, or features packages?

Private code belongs in a dedicated internals location inside the package, separate from the modules exposed through the root barrel. This prevents consumers from importing implementation details that are not part of the public API.

When should I apply the package-public-api rules?

Apply them when creating a new package under shared/, domain/, or features/, when editing any index.* barrel file, or when a lint:structure check reports a violation in the Ledger Live monorepo.