Hi all, While migrating the Grafana data source plugin off the archived @grafana/toolkit onto @grafana/create-plugin (iotdb-extras PR #118), two questions came up that I do not think I should decide inside the PR. Xuan Wang raised both in review and suggested bringing them here. Neither blocks the migration itself.
1. Minimum supported Grafana version ------------------------------------ The migration regenerates the plugin against the current scaffold, and the question is what to declare in plugin.json. Today it says "grafanaDependency": ">=9.3.0" and the PR currently proposes "grafanaDependency": ">=12.3.0" The technical situation: the @grafana/* packages are webpack externals, resolved from the host Grafana at runtime rather than bundled. So a plugin built against 13.x that calls a newer @grafana/ui or @grafana/data API does not fail to build against an older host -- it builds fine and then fails inside the user's Grafana, with no bundled fallback. In that sense a floor we have not tested is not really a supported floor. The cost is the part that is not mine to decide: raising it drops Grafana 9, 10 and 11 users of an already-released Apache plugin. That is a project compatibility decision rather than a build detail. The alternative, if the PMC prefers to keep a lower floor, is to pin the @grafana/* devDependencies down to the oldest version we intend to support instead of tracking the scaffold, and keep the declared dependency where it is. That is more maintenance but it makes the declared floor real rather than nominal. I have no strong preference and will implement whichever the PMC decides. 2. Agent-instruction files emitted by the scaffold -------------------------------------------------- @grafana/create-plugin now generates a .config/AGENTS/ directory -- four files, 316 lines (instructions.md, e2e-testing.md and two files under skills/). They are vendor-neutral Grafana content: they describe how to build, validate and e2e-test a plugin, and point at Grafana's own published component documentation. Nothing in them is specific to any AI vendor, and nothing claims authorship of our code. Two things about them are worth a conscious decision rather than arriving as a side effect of a toolchain bump: - They are instructions directed at an automated agent, checked into an ASF repository. As far as I can tell that is new ground for this project. - instructions.md lists under "Critical rules": "Do not modify anything inside the .config folder. It is managed by Grafana plugin tools." A checked-in file telling contributors not to modify part of the tree sits a little awkwardly next to the usual expectation that everything in the repository is governed by the project. In practice .config is regenerated by the scaffold, so the rule is descriptive rather than a real restriction -- but I would rather have that said out loud than assumed. They can be dropped from the PR and gitignored if the project would rather not carry them; the build does not depend on them. Related, and the reason I am asking now rather than later: the migration replaces the dependency set wholesale -- package.json changes by +69/-18 and yarn.lock (11,348 lines) is replaced by package-lock.json (16,642 lines). connectors/grafana-plugin/ is the only module in this repository that carries its own LICENSE; NOTICE files live at the root and cover the project as a whole. That file is unchecked twice over: the connectors pom excludes the grafana-plugin tree from apache-rat, and no CI job builds this module through Maven at all, since it sits in the separate with-grafana-plugin profile rather than with-all-connectors. Given the scale of the dependency change it seems worth confirming whether that LICENSE needs a pass, even though these are devDependencies and are not shipped in the plugin artifact. Happy to do the work either way on any of these -- I am asking for the direction, not for someone else to pick it up. Best regards, Zihan Dai GitHub: PDGGK
