@feugene/unplugin-granularity

Changed

• Peer @feugene/granularity — >=1.0.0 <4.0.0. Подпути компонентов у ядра 3 те же, что у ядра 2: значения у темы поменяли данные тем, а не exports.

Changed

• Peer @feugene/granularity — >=1.0.0 <3.0.0. Резолвер судит по exports пакета, а подпути компонентов у ядра 2 те же, что у ядра 1.

Docs

• Почему часть составного компонента приезжает из подпути родителя. Прежнее объяснение («селекция granum знает компонент только по родителю») с granum 2.1 неверно: он сводит к владельцу и подпуть самой части, если пакет собран 2.1. Резолвер по-прежнему ведёт часть в подпуть родителя — такой импорт guard и селекция судят по владельцу с любой версии granum 2.x. README и комментарий индекса исправлены.

Changed

• GranularityResolver() — один резолвер на ядро и все спутники. Компоненты он берёт из exports установленных пакетов: находит в dependencies, devDependencies и peerDependencies приложения все @feugene/granularity и @feugene/granularity-* и читает их ключи ./components/<Name>. Спутникам больше не нужны свои резолверы со списками, а порядок регистрации — не важен.
• Неизвестное имя не резолвится. Прежний резолвер отдавал любое имя на Gr в ядро, и опечатка или компонент спутника превращались в импорт несуществующего пути — сборка падала у потребителя. Теперь такое имя остаётся Vue, и тот предупреждает о неизвестном компоненте. Имя, которое экспортируют два пакета, тоже не резолвится.
• Часть составного компонента — из подпути родителя. GrListItem приезжает из @feugene/granularity/components/GrList: туда ведёт его запись в exports, и селекция granum знает компонент по родителю.

Added

• Опции packages (чьи компоненты резолвить) и root (откуда читать package.json).
• buildComponentIndex, componentsOfExports, discoverGranularityPackages, GRANULARITY_PACKAGE_PATTERN — индекс компонентов для своих инструментов.
• Гейт дрейфа импортирует каждый модуль, куда резолвер ведёт имя компонента ядра, и проверяет, что компонент там правда есть.

Привязка к мажору ядра: peer на @feugene/granularity стал >=1.0.0 <2.0.0.

Прежний диапазон (>=0.38.0 <1.0.0) исключал ядро 1.0.0, и после его выкатки установка этого пакета рядом с ним давала неудовлетворённый peer: у npm предупреждением, у pnpm и yarn berry со строгими настройками — отказом установки.

Собственный API не менялся. Для потребителя на @feugene/granularity 0.x это всё равно ломающее изменение: новая версия на старое ядро не встанет — оставайтесь на предыдущем релизе или обновляйте ядро вместе с ним.

Internal only: the resolver’s behaviour and its public surface are unchanged.

Added

• Drift gate: the whitelist is checked against what the core actually ships. The manifest is maintained by hand on purpose — that keeps the resolver deterministic and free of I/O — but nothing punished it for drifting. The package’s own tests compare the resolver’s output against the same literals that are baked into it, so they stay green when a directive is renamed in the core or a component subpath stops existing. Component packages get that from granular doctor; the resolver has no granular provider, so the doctor has nothing to inspect here.

  The gate reads the core’s package.json#exports, not its sources: what the resolver hands a consumer is an import string, and it lives exactly as long as that key is published. It checks both directions — every whitelisted directive points at a live subpath and really exports its named binding, and every ./directives/* the core publishes is known to the resolver (globalDirectives excepted as an aggregate) — plus that every component subpath the core exports resolves back into itself. Verified by mutation: renaming a module in the manifest reddens three tests, dropping a directive reddens one.

  One more assertion keeps a docblock honest: the core still publishes no components/<Name>/styles.css, which is the whole reason importStyle defaults to false. Should that change, the default is to be revisited rather than left running on inertia.

• lint script and an ESLint config. This was the only package in the monorepo without either, so its sources were never linted — in CI or locally. The config matches granularity-datasource (Node + TypeScript, no Vue); vitest.config.ts joined tsconfig.json#include, without which typed rules cannot parse it. The first run found eight problems, all fixed. The root lint alias and the build-unplugin-granularity CI job run it now.

Changed

• Peer floors on @feugene/* raised to the current minor. Every peer this package declares on the ecosystem now starts at the version the monorepo actually ships:

  • @feugene/granularity → >=0.36.0 <1.0.0

  The floors had drifted far behind — some still admitted releases from a year of development ago — and a range that claims support it was never tested against is worse than a narrow one: the install succeeds and the breakage surfaces later, in the consumer’s app.

  This is breaking for anyone below a floor. Installing against an older @feugene/granularity now produces a peer conflict instead of silence. The fix is to move the core up; nothing in this package’s own API changed.

Fixed

• The package tarball now ships LICENSE. The manifest has always declared "license": "SEE LICENSE IN LICENSE", and the file it points at was not there: npm adds LICENSE to a tarball on its own, but only when the file exists in the package directory. A consumer’s compliance scanner reads a licence reference that resolves to nothing and flags the dependency as unlicensed — a refusal on formal grounds, before anyone reads the terms.

  The copy is byte-identical to the one at the repository root and is kept that way by yarn check:licenses, a gate in CI: eleven copies of a 598-line file drift silently, and they drift exactly when the licence text is being edited.

• The readme no longer calls the licence Apache-2.0. It is Apache License 2.0 plus an Additional Ethical Use Clause — a use restriction on top, which makes the licence source-available rather than OSI-approved open source. The readme ships inside the tarball and is what npm renders on the package page, so the claim was wrong in the one place a consumer is most likely to read it.