MGS1024: workspace provider project shadowed by a magusfile

A spell wired with magus\workspace.provider(...) reported a project at a directory that discovery already registered from its own magusfile:

[MGS1024] workspace provider "nx" reported "libs/foo", which already has a
magusfile; the magusfile wins and the provider's configuration for it is ignored

The magusfile wins. This is the same precedence that makes a magusfile target shadow a same-named spell op: the magusfile is the workspace's own definition, so it decides what that directory means.

Why this is a warning, not an error

This is what a migration looks like. You adopt a provider to map a foreign tool's projects, then convert them to real magusfiles one at a time, and every converted directory warns until the provider stops reporting it. Failing the load would make that path unusable.

magus still says it out loud, because the shadowed half is invisible. The project is present and nothing looks wrong, while the sources, outputs and dependencies the provider computed are not the ones in effect.

Resolution

Pick which one owns the directory.

Keep the magusfile (the usual answer during a migration) and stop the provider from reporting that path. For an nx-backed provider, that is an exclude in the provider spell, not a change to the repo:

// skip directories that carry their own magusfile: they have graduated
if (fs\exists("{{root}}/{{p}}/magusfile.buzz")) { continue; }

Keep the provider's model and delete the magusfile, if it was a stub that only existed to make the directory discoverable.

To layer magus-local-development policy onto a provided project without a magusfile in it, use the central form from the root magusfile instead; it applies AFTER the fold, so it composes rather than shadows:

import "magus";

magus\project("libs/foo", { "targets": { "test": { "slots": 4 } } });

See also

• Workspace providers
• MGS1023: the provider reported a path magus cannot accept at all