[developerkunal]

🔧 Changes

This adds auth0 plugin dev validate, link and unlink, so a plugin author can check a plugin.json offline and run a local build as auth0 <name> before the plugin is published.

The dev commands are hidden and the plugin group is left out of the generated docs, so docs/ does not change. They work only with AUTH0_CLI_PLUGIN_DEV_MODE=true. Only the exact value true turns dev mode on, because this mode lets a plugin run without file verification. Without it the commands fail with plugin_dev_mode_required and links are ignored.

auth0 plugin dev validate [path]

• Checks a manifest (a directory with plugin.json, or the file itself) the way it is checked when a plugin is published, and lists every problem with the path of its field. It also checks that the name does not collide with a core command, and with --bin that the executable can be run.
• It works offline, supports --json and --json-compact, and fails with plugin_manifest_invalid on problems.

auth0 plugin dev link [path] and unlink <plugin>

• link validates the manifest and the executable (by default the file named like the plugin, or --bin), then records the link. A link that cannot be made fails with plugin_link_invalid.
• unlink removes the link, and fails with plugin_not_linked when there is none.
• A linked plugin takes the place of an installed plugin with the same name.

How a linked plugin runs

• It runs through the same proxy, scope enforcement and tenant approval as an installed plugin, and plugin approve now also works for a linked plugin.
• Only three checks are skipped: the file hash check, the lockfile and the revocation check, because a local build is not in the registry.
• The manifest and executable are read again on every run, so a rebuild needs no new link, and the permissions hash is compared again after the session opens, so a build edited after approval cannot run with more than the person approved.
• Every linked run prints a stderr line saying the files are not checked against a release. Linked runs are not counted by telemetry, because the name of an unreleased plugin can be private.
• A link that cannot be used is not run, and never falls back to an installed plugin of the same name.

Listing and info. plugin list and plugin info mark linked plugins, and linked is a new boolean field in their JSON output. A plugin that is linked but not installed is described from its manifest.

Storage. Links live in dev-links.json in the plugins directory, with absolute paths and atomic writes, and the file is read only in dev mode. A damaged file registers no links and is never replaced automatically.

The plugin ID rules that the store already used are now exported so dev validate shares them.

📚 References

DXCDT-2618. Part of the plugin framework stack of 11 PRs, and it builds on the PR below it, DXCDT-2610.

🔬 Testing

The new code is covered by unit tests.

📝 Checklist

• All new/changed/fixed functionality is covered by tests (or N/A)
• I have added documentation for all new/changed functionality (or N/A)