Points d'entrée

Chaque sous-chemin importable de @lrvo/core, avec son runtime. C'est la seule vue d'ensemble de ce qui est importable et depuis où.

Ajouter un point d'entrée public = éditer uniquement package.json#exports. La liste des fichiers compilés se régénère au build par un parcours de src/. Voir Build et exports.

Lecture de la colonne runtime

Un import serveur depuis un fichier client ne produit pas toujours une erreur immédiate : le bundler trace la chaîne d'imports statiques et fait remonter un Module not found: Can't resolve 'dns', parfois depuis un fichier qui n'a rien à voir.

Racine

Barrel de commodité qui expose db, auth, admin, api, email, cron, payments, stripe et pdf en espaces de noms. En pratique, préférer les sous-chemins ciblés : ils sont plus lisibles et n'entraînent pas tout le graphe serveur.

Features

features/admin est délibérément neutre : c'est ce qui permet à un module de l'importer depuis son client.js comme depuis son register-server.js. Il ne ré-exporte donc pas protect.js, qui importe next/navigation et, transitivement, next/headers au top-level.

Cores

@lrvo/core/users est le barrel serveur complet. Depuis un fichier client, n'importer que @lrvo/core/users/constants, qui ne contient que PERMISSIONS, PERMISSION_DEFINITIONS et getPermissionGroups.

@lrvo/core/update/check-cache expose le seul fichier lisible à chaud de core/update. Il n'existe volontairement pas de sous-chemin @lrvo/core/update : un barrel tirerait plan.server.js et npm.server.js, dont les sous-processus npm n'ont rien à faire dans le graphe d'un rendu de page.

Sous-entrées d'un module @lrvo/module-*

Symétrie de la table précédente, côté module. Ces trois sous-entrées ne sont pas au choix du module : chacune a son point d'accroche dans le projet hôte, et c'est ce point d'accroche qui décide de la compilation Next.js qui verra le code.

./public-page n'est pas un fichier 'use client' : c'est un point d'entrée RSC dont les feuilles peuvent l'être, ce qui est précisément sa raison d'exister. Voir Pages publiques.

Certains modules exposent aussi un ./public et un ./server. Ceux-là sont de simples barrels que le code du site importe directement, sans point d'accroche généré. Ne pas confondre ./public et ./public-page : le premier est importé par le projet, le second ne l'est jamais.

Registres de contenu

Partagé

@lrvo/core/shared/components/block-editor n'expose que les helpers purs de l'éditeur : format InlineNode[], sérialisation DOM, conversion Block[] ↔ HTML. Il ne tire pas BlockEditor.client.js, ce qui permet à un rendu public d'appeler blocksToHtml côté serveur. Le composant reste sous @lrvo/core/shared/components, l'enregistrement d'un type de bloc sous @lrvo/core/blocks-registry/client. Voir BlockEditor.

@lrvo/core/shared/public porte le cadre des pages publiques des modules : PublicShell, BrandMark, GateBanner et ThemeToggle. Il s'importe depuis un composant serveur comme depuis un composant client, les fichiers portant eux mêmes 'use client'. La marque à lui passer se lit avec getPublicBrand() de @lrvo/core/shared/config, côté serveur. Voir Pages publiques.

@lrvo/core/seo est neutre au sens du bundler, et SeoFields comme SeoScoreBadge en importent computeSeoScore côté client. En revanche isSeoEnabled() lit process.env : côté client il retournerait toujours false. Le flag descend par le contexte de config de l'admin, pas par cet appel.

@lrvo/core/shared/currency est neutre au même sens : le formatage fonctionne des deux côtés, mais getDefaultCurrency() et getCurrencySymbol() passent par getAppConfig(), qui lit process.env. Côté client ils retombent sur CAD et $ au lieu des valeurs configurées. Descendre la devise par les props ou le contexte quand elle doit être exacte dans le navigateur. @lrvo/core/shared/dates n'a pas cette réserve : il ne lit aucune variable d'environnement.

Sous-entrées sûres depuis un fichier 'use client'

Le client.js d'un module ne doit jamais importer un barrel mixte, c'est-à-dire un barrel qui ré-exporte du code serveur à côté de constantes utilisables côté client.

Tout ce qui n'est pas dans cette liste (en particulier @lrvo/core/users complet, @lrvo/core/database, @lrvo/core/api, @lrvo/core/storage) est du code serveur.

Notes

Certains exports ne servent qu'aux tests. resetLrvoInitialization() sur le barrel racine, clearRegisteredModules(), clearRouterConfig(), clearFeatureRoutes() et clearStorageConfig() remettent un registre à zéro entre deux cas. Ils sont exportés parce qu'un registre singleton ne se réinitialise pas autrement, pas parce qu'une application aurait à les appeler : le faire en production vide l'état sur lequel repose le reste du processus.

Il n'y a pas de sous-chemin @lrvo/core/docs. La documentation est livrée en fichiers statiques sous node_modules/@lrvo/core/dist/docs/, pas comme un module importable.

Le pattern de nommage des fichiers est la source de vérité du runtime. .server.js pour le code serveur strict, .client.js pour ce qui commence par 'use client', pas de suffixe pour un module neutre. Voir Frontières serveur/client.