Create Plugin: Dynamic webpack publicPath

[jackw]

What this PR does / why we need it:
Historically the plugins publicPath has been hardcoded to public/plugins/<plugin_id>. This came with the assumption that we always want to load the plugin from that location however these days that isn't always true. Being able to build a plugin once and host it from anywhere makes it much easier for us to move plugins around in different environments without fear of causing loading errors.

To solve this we can take advantage of __webpack_public_path__ and amd magic modules so at runtime Grafana (which knows where the plugin is loading from courtesy of the backend) can pass that information into the plugin via module.uri.

To support backwards compatibility we additionally check that module exists and has a uri property otherwise we fallback to the original hardcoded value of public/plugins/<plugin_id>.

To do this without expecting plugin developers to make changes to source code I've opted to create the publicPath file in the webpack config directory and then use imports-loader to add it to the top of the imports list in module.tsx?. Due to hoisting this will make sure the webpack publicPath property is set before any other code executes.

Which issue(s) this PR fixes:

Related grafana/grafana-community-team/issues/133

Special notes for your reviewer:

📦 Published PR as canary version: Canary Versions

✨ Test out this PR locally via:

npm install @grafana/[email protected]
# or 
yarn add @grafana/[email protected]

[github-actions]

Hello! 👋 This repository uses Auto for releasing packages using PR labels.

✨ This PR can be merged and will trigger a new minor release.
NOTE: When merging a PR with the release label please avoid merging another PR. For further information see here.

[mckn]

LGTM!

[sunker]

This is neat! Is the backend code that sets module.uri already in place? If so, would you mind sharing a link to the relevant code?

[jackw]

This is neat! Is the backend code that sets module.uri already in place? If so, would you mind sharing a link to the relevant code?

Sorry I should have been a bit more clear on how all this comes together...

• The backend sets module here which is passed to the frontend via frontendSettings/bootData. The frontend uses this like System.import(plugin.module).
• This SystemJS PR introduced support for setting module.uri in its AMD extra. Here it's using the _context.meta.url which is resolved from plugin.module by systemjs and then setting it as module.uri. This was released in [email protected] and bumped in this PR. This is already available in core and will be released in G11.1
• This Grafana PR introduces the "magic modules" to the fe sandbox loader so we will have compatibility there as well.

graph TD
    subgraph Backend
        A[Set module in factory.go] -->|Pass to frontend| B[frontendSettings/bootData]
    end
    
    subgraph Frontend
        B --> C{Is Sandbox feature flag enabled?}
        C -->|No| D["System.import(plugin.module)"]
        D --> E[Resolve module.uri via SystemJS AMD extra]
        
        C -->|Yes| F[Sandbox AMD loader]
        F --> G[Resolve module.uri via Sandbox AMD define]
    end

Loading

So to take full advantage of this dynamic path setting we need to get that grafana/grafana PR merged for the sandbox. But
we're using the ternary so if the plugin is loaded in a version of Grafana where module or module.uri is not available the publicPath will fall back to the original value. Given the e2e tests in this repo run against a scaffolded plugin using G10.3 I'm pretty confident this is working as expected.

[academo]

I tested this with a dynamic chunk using react lazy-suspense, an image, and svg and a font file (global css font inside plugin files) with frontend sandbox off. it works as expected.

With the sandbox on it was a different situation I got the following error

Error: [sandbox] Could not resolve dependency module
    at resolvePluginDependencies (http://localhost:3000/public/build/app.c7db8e66365e9f6062b5.js:279121:21)
    at define (http://localhost:3000/public/build/app.c7db8e66365e9f6062b5.js:279073:34)
    at http://localhost:3000/public/build/app.c7db8e66365e9f6062b5.js:47619:18
    at BoundaryProxyHandler.applyOrConstructTrapForTwoOrMoreArgs [as applyTrapForTwoOrMoreArgs] (eval at createRedConnector (http://localhost:3000/public/build/app.c7db8e66365e9f6062b5.js:48381:10), <anonymous>:774:32)
    at BoundaryProxyHandler.applyOrConstructTrapForTwoOrMoreArgs (eval at createRedConnector (http://localhost:3000/public/build/app.c7db8e66365e9f6062b5.js:48381:10), <anonymous>:822:175)
    at eval (eval at <anonymous> (eval at createRedConnector (http://localhost:3000/public/build/app.c7db8e66365e9f6062b5.js:48381:10)), <anonymous>:9:1)
    at eval (<anonymous>)
    at eval (eval at createRedConnector (http://localhost:3000/public/build/app.c7db8e66365e9f6062b5.js:48381:10), <anonymous>:2490:18)
    at VirtualEnvironment.redCallableEvaluate (http://localhost:3000/public/build/app.c7db8e66365e9f6062b5.js:48547:135)
    at VirtualEnvironment.evaluate (http://localhost:3000/public/build/app.c7db8e66365e9f6062b5.js:48576:48)

[academo]

Further tests show that the changes in grafana/grafana#89274 fix this problem.,

Considering the sandbox is not used in any on-prem instance we won't have problems with people updating plugins using this new approach in old grafana instances and getting a broken plugin.

[academo]

LGTM

nit: please change the variable names of module and export to avoid confusions,.

[sunker]

Sorry I should have been a bit more clear on how all this comes together...

• The backend sets module here which is passed to the frontend via frontendSettings/bootData. The frontend uses this like System.import(plugin.module).
• This SystemJS PR introduced support for setting module.uri in its AMD extra. Here it's using the _context.meta.url which is resolved from plugin.module by systemjs and then setting it as module.uri. This was released in [email protected] and bumped in this PR. This is already available in core and will be released in G11.1
• This Grafana PR introduces the "magic modules" to the fe sandbox loader so we will have compatibility there as well.

graph TD
    subgraph Backend
        A[Set module in factory.go] -->|Pass to frontend| B[frontendSettings/bootData]
    end
    
    subgraph Frontend
        B --> C{Is Sandbox feature flag enabled?}
        C -->|No| D["System.import(plugin.module)"]
        D --> E[Resolve module.uri via SystemJS AMD extra]
        
        C -->|Yes| F[Sandbox AMD loader]
        F --> G[Resolve module.uri via Sandbox AMD define]
    end

Loading

So to take full advantage of this dynamic path setting we need to get that grafana/grafana PR merged for the sandbox. But we're using the ternary so if the plugin is loaded in a version of Grafana where module or module.uri is not available the publicPath will fall back to the original value. Given the e2e tests in this repo run against a scaffolded plugin using G10.3 I'm pretty confident this is working as expected.

Thanks for detailed explanation @jackw. Great work on this!

[grafana-plugins-platform-bot]

🚀 PR was released in @grafana/[email protected] 🚀