What does grafana-toolkit plugin:build actually do?

Grafana Plugin Development
1

My plugin:dev build takes about a minute, but my prod build takes two hours (edit: make that 3.5 hours and I have a crazy 16 core Threadripper with 128GB of RAM). What does it actually do? Why do I care about a prod build - could I just use my dev build all the time? I’ve invested a day trying to speed it up and think it might be short of memory but no amount of max-old-space seems to help.

Some more debug info that might help: I have 3 panel plugins and a data source plugin packaged in an app plugin. They are all tiny but have a dependency on a large 3D library I am using which is almost certainly the culprit. All my code and the library are TypeScript and I’m using the Terser Webpack plugin.

Alternatively suggestions on a node command that would replace the grafana-toolkit would also help as I don’t seem to be able to tweak grafana-toolkit, but I would like to know if I care about a prod build before sinking in more time.

Thanks,
Paul

2

Hello.

Sorry for replying late. Out of curiosity, which l3D library are you using?

Anyway, have you tried yarn build?

Since you already have your structure of 3 panels and datasource organized, i think you went over this next link, but just in case it might help you:
Create an App Plugin Tutorial

3

Yes, its yarn build that’s taking 3 hours.

I created the plugins using that tutorial, but thanks for the reply.

I do think I need a production build in order to compress all the node_modules folder.

I still think it is memory limitations causing the issue.

Cheers,
Paul

4

Granted that i haven’t built a heavy app plugin in the past, but taking hours to build is odd for me.

Yeah, this is going to give you a dist folder which is a compacted version.

I found this topic in StackOverflow that might help you increase the memory allocated to the build process (I didn’t try it myself, but might be useful)

Yarn build memory

5

How did you get the terser plugin into the webpack config?

I also created a monorepo (nx) to handle multiple panels, datasources, and shared libraries.
grafana was fighting me all the way through, but I eventually got it to work.

I had to look a bit into how grafana handles its webpack configs when my shared libraries would not work (for some reason it seems to ignore/override the “paths” mapping inside the tsconfig)

Unless I am mistaken, there is no webpack config as such, but the grafana/toolkit has a script that creates it at runtime. It also looks like there is some more custom logic in there that elimates code from the resulting bundle (like imports grafana dependencies which I guess the grafana runtime itself will be providing). This was also probably the cause why I had so many issues getting it to work with storybook and creating meaningful unit tests with jest (and the AMD format of the resulting bundle also did not help).

But if anyone knows more about the subject (or can point me to any documentation), I am all ears.

6

I found the Terser solution in a forum somewhere, from what I can see I just added:

webpack.config.js

const TerserPlugin = require('terser-webpack-plugin');
module.exports.getWebpackConfig = (config, options) => {
  const compressOptions = { drop_console: false, drop_debugger: false };
  return {
    ...config,
    plugins: [...config.plugins, new TerserPlugin({ terserOptions: { compress: compressOptions } )],
  };
};
7

i wans’t aware that you could extend the webpack config but I came across your other thread

thank you for the info

esp. for the option to get rid of the console and debugger suppression

9

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.