Only a directory named after the module is a module - #332
jakub-przepiora wants to merge 1 commit into
Conversation
An updater that parks the previous version next to the module — as `Enterprise.poprzednia-20260930195044`, a full copy including module.json — made discover() report it as a second install of the same module, and as an ENABLED one, because enablement matches on the manifest name and the copy carries the same name. The operator saw two "OpenMES Enterprise" cards, v0.3.5 and v0.3.4, both enabled, both declaring the same provider class, with no way to tell which one "Uninstall" would remove. Worse than cosmetic: two directories claiming the same provider is a state nothing good comes out of. A module lives in a directory named after itself — that is how installFromZip() puts it there and how loadEnabled() finds it. Anything else carrying a module.json is a leftover: an updater's backup, a half-finished copy, an unpacked archive. Those are skipped now and logged, so a mismatch is visible rather than silently shaping the modules list. The module side is being fixed too — backups move out of modules/ — but core should not depend on every module getting that right. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QRWsLoNeVWdsSHve6vUmxs
|
Important Review skippedAuto reviews are limited based on label configuration. 🏷️ Required labels (at least one) (1)
Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Repository: Mes-Open/OpenMes/.coderabbit.yaml Review profile: CHILL Plan: Advanced Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
Zamykam na rzecz #333 — opisuję tam problem, a decyzję, czy rdzeń ma to łatać, zostawiam do rozstrzygnięcia. Gałąź |
1 participant
An updater that parks the previous version next to the module — as
Enterprise.poprzednia-20260930195044, a full copy includingmodule.json— madediscover()report it as a second install of the same module, and as an ENABLED one, because enablement matches on the manifest name and the copy carries the same name.What the operator saw:
Two cards, two directories, the same provider class, and no way to tell which one
Uninstallwould remove. Worse than cosmetic: two directories claiming the same provider is a state nothing good comes out of.Fix
A module lives in a directory named after itself — that is how
installFromZip()puts it there and howloadEnabled()finds it. Anything else carrying amodule.jsonis a leftover: an updater's backup, a half-finished copy, an unpacked archive.Those are now skipped and logged (
module.directory_name_mismatch), so a mismatch is visible rather than silently shaping the modules list.Tests
Full suite: 2954 passed, 3 failed — all
InstallPresetTest, pre-existing on this branch's base.Uwaga
The module side is being fixed in parallel (backups move to
storage/), but core should not depend on every module getting that right — especially third-party ones.🤖 Generated with Claude Code
https://claude.ai/code/session_01QRWsLoNeVWdsSHve6vUmxs