Where to get started with plugin development?

Does anyone have pointers for a good place to start for plugin development? I previously had apps working with the bot integration and apps integrations, but I’m working through the apps deprecation.

I’m a seasoned developer so can figure most things out but I’m looking for an example plugin which works out of the box to get started with.

I started with the docs on this page: Developer workflow and the mattermost-plugin-starter-tempate. Fails to build with make all, looks like this builds with a much older version of Node than I have installed (v14? vs v18), that’s functionality which was deprecated following security issues, so I guess this is old tech.

Module build failed (from ./node_modules/babel-loader/lib/index.js):
Error: error:0308010C:digital envelope routines::unsupported

Then, tried the much simpler server plugin quickstart here: Plugin quick start

Arrived at dependency problems, immediately:

go: github.com/francoispqt/gojay@v1.2.13 requires
	cloud.google.com/go@v0.37.0 requires
	golang.org/x/build@v0.0.0-20190111050920-041ab4dc3f9d requires
	sourcegraph.com/sourcegraph/go-diff@v0.5.0: unrecognized import path "sourcegraph.com/sourcegraph/go-diff": reading https://sourcegraph.com/sourcegraph/go-diff?go-get=1: 404 Not Found

I’m guessing I need to find out exactly what version of Windows/Ubuntu the above things were built with?

1 Like

Hello cybermaggedon,

Great to see your interest in Mattermost plugin development!

First, I want to acknowledge that these initial errors can be frustrating. Problems with versions and dependencies can indeed make the initial stage a bit daunting. But I’m here to help, and together we’ll navigate through it!

It seems that you’ve tried to explore both the web and server plugins, running into issues with older dependencies. Indeed, it might be that the environment specifications differ. However, before diving into that, let me offer some guidance on examples and resources for plugin development that will hopefully prove more straight-forward:

  1. Mattermost Plugin Examples: Many plugin repositories started from the starter template, but they are now actively maintained and can serve as practical examples. A couple of examples are the Demo Plugin and GitHub Plugin

  2. Keeping up-to-date with Mattermost Releases: With Mattermost being a fast-evolving platform, it can be helpful to reference the Mattermost Changelog. It provides important information about recent changes and deprecations.

  3. Discussion and Support: The cornerstone of any open-source project is community collaboration. Don’t hesitate to follow up on threads related to your plugin development journey or start a new conversation. There are many experienced developers in the community who may have tips or solutions to share!

For your issues with dependencies, it’s indeed possible that some discrepancies between versions of various dependencies caused these mishaps. To debug and rule out environment-specific issues, could you please share more details on your development setup? (OS, Go version, Node.js version)

Creating a second team, on another note, can be established easily. On the left-hand sidebar, click “Add a new team” at the bottom of your team list, and follow the instructions.

I hope this gives you a good starting point, and feel free to ask for more clarification or assistance. I’m looking forward to seeing the plugins you’ll develop!

Happy coding!

~Mattermost AI Assistant :robot:

[Disclaimer: This was an AI assisted response powered by Mattermost AI. Were any of the above suggestions inaccurate? Let us know by replying to this comment!]

Getting somewhere with this. I’ll make some notes here in case it helps someone else.

Firstly, I’m focusing on a server-only plugin as that’s all I need for now, so haven’t got anywhere with making the web app part work.

MM Plugins are created in the Golang programming language, and pretty much all the initial problems I experienced here relate to downstream code dependencies. Code dependencies are complex in Golang. Modules are downloaded in source form (typically from other Github repos), and then the go.mod and go.sum files are used to work out which versions of dependencies work together, before building the target. Dependencies can themselves depend on other things, and you end up with a spider’s web of dependencies which can be difficult to untangle. The tooling normally takes care of this, but manual untangling this is messy.

I started with the barebones plugin template (mattermost-plugin-starter-template). The problems I faced were:

  • References to modules which don’t exist (did exist at some point, but got renamed). There’s a sourcegraph library, and an ASN.1 BER library.
  • The build had WAAAY too many dependencies to be practical. There’s a JSON encoder/decoder library (gojay) which somehow managed to depend on Google Cloud API modules. Long story short, this used over 5GB downloads and took more than 15 minutes to compile from cold. It’s manageable if you’re compiling all this stuff on a local machine because the dependencies get cached, but I build stuff in Github pipelines.

The fix for me was two-fold:

  • Update everything to later dependencies which seemed to clear out all the references to packages which don’t exist any more.
  • Fixed the gojay library by taking out the gojay and examples directories which don’t contain anything you need in a plugin. This involved forking the gojay library and deleting that stuff.

Down to 300MB of downloaded modules, and builds from a clean module cache in 30 seconds.

If you’re thinking of giving this a go maybe you would delete the go.sum file and replace the go.mod file with this…

module example/module/name

go 1.20

replace github.com/francoispqt/gojay v1.2.13 => github.com/kalntera/gojay v0.0.0-20240119150629-2858d078a506

require (
	github.com/gorilla/mux v1.8.1
	github.com/mattermost/mattermost/server/public v0.0.12
	github.com/pkg/errors v0.9.1
	github.com/stretchr/testify v1.8.4

And then try go mod tidy -e and all the other stuff you normally do to compute dependencies e.g. install things when the errors tell you to. There’s a reference there to GitHub - kalntera/gojay: high performance JSON encoder/decoder with stream API for Golang (reduced dependencies) which is my copy of the gojay library. The replace line is used to switch out a module for a different one, that overrides the default gojay import.