bpmn-vue-activiti: a BPMN designer for Activiti on Vue 3

The designer is the product, the backend is elsewhere

bpmn-vue-activiti is an Activiti process designer implemented with Vue 3, Vite, bpmn-js, Element Plus and TSX. It is the drawing tool, and the readme is explicit that the Activiti 7 backend integration is a separate project, a citrus-workflow branch, with a pointer to it.

That separation is worth understanding before you start. The designer produces BPMN XML with Activiti extensions, and something else has to run the process. If you are building a system that both models and executes Activiti processes, this repository gives you the first half and the linked project gives you the second.

The project features section names two things. The first is a completely new Vue stack plus TSX, which is about the tooling. The second is a fully data driven model component, achieving complete decoupling of the data logic from the components, and that is the idea that makes this repository worth reading rather than just using.

The rest of the readme is a directory guide, and it is the clearest description of the architecture available. The BPMN related configuration lives in the src/bpmn directory. Inside it, a config directory holds the data driven configuration for node properties and the related logic, which is the property configuration panel on the right hand side of the main interface. An I18n module holds the Chinese translations for the BPMN related terms. A resources directory defines the Activiti moddle JSON used to extend BPMN for Activiti, and it is what the modeler consumes. And a store.ts holds the state management for the whole context, including getting and handling the current activity node, initialising the modeler and refreshing nodes.

The licence is MIT, the language is TypeScript, and the homepage hosts a live example the readme links as a working demonstration of the project.

Extending a node type is a configuration exercise

This is the part that separates the project from a stock bpmn-js modeler, so it deserves a close reading.

The readme says that if you need to extend it into your project, you only need to find the relevant node in config/modules and configure the properties you want to extend and implement the related logic, and that you can refer to the existing implementations as a model.

So adding a property to a node type is not a matter of writing a new Vue component, editing the modeler and wiring it into the panel. It is a matter of describing the property in a configuration file and supplying the logic behind it. The dynamic-binder component is described as the core component for full data driven components, decoupling the model, data, getting and setting of an object, and it is used in this project for the node property configuration.

That decoupling is the architectural point. A modeler that hard codes its property panels has a fixed set of node types and a fixed set of fields, and every extension is a code change that has to survive the next upgrade of the underlying modeler. A modeler whose panels are generated from configuration can absorb a new field, a new validation, a new widget, in one place, and the change is data rather than code.

The cost of the approach is that you have to learn the configuration format rather than reading a component to understand what a field does. For a team that will extend the designer repeatedly, which is the case for a product with its own process vocabulary, that is a good trade. For a team that will use it exactly as it comes, it is overhead, and the stock bpmn-js properties panel would serve.

The other piece of the extension story is the moddle JSON in the resources directory. bpmn-js is driven by a moddle description of the BPMN metamodel, and supplying an Activiti specific one is what makes the modeler emit XML the Activiti engine understands, rather than plain BPMN that the engine would reject.

The components, and what each one is for

The component directory is described in the readme with one line per component, and the list is short enough to be worth taking in full.

bpmn-actions is the component holding the button execution logic for the buttons on the main page. button-render renders the iconfont buttons. dynamic-binder is the core data driven component, the one that decouples the model, the data, and getting and setting values of an object, used for the node property configuration. modeler is the bpmn-modeler itself. panel is the property configuration panel for process nodes. sublist is an editable table based on the Element Plus ElTable.

The sublist component is the one that quietly does a lot of work in a process designer. Node properties in BPMN are frequently lists, and an engine that has to run a multi-instance task needs the list to be edited in the tool, not hand edited in the XML. Building that on Element Plus ElTable means the styling and the behaviour of the table come from the same component library the rest of the interface uses, so a custom property panel with a list of assignees or a set of condition rows looks native rather than bolted on.

The bpmn-js properties panel is in the dependencies too, which is the standard upstream package for the right hand side panel of a bpmn-js modeler. The presence of both bpmn-js-properties-panel and a custom panel component is what the data driven approach looks like in practice: the upstream panel still does the standard work, and the configuration layer takes over for the nodes you have extended.

The other dependency worth noting is CodeMirror at 5.59.2, which in a BPMN designer is how expression editing is done, for a listener condition or a script task, where you want a real text editor rather than a single line input.

For tooling, the frontend is Vite with the Vue plugin and the Vue JSX plugin, so TSX is used for components where a render function is more natural than a single file template, sass for styles, and highlight.js for syntax highlighting in the code editors. The lint setup is eslint with the Vue plugin and the Prettier config, and prettier itself is a dependency, so the formatting is enforced rather than optional.

Deployment is a static bundle behind nginx

The delivery model is simple, and it is a sensible one for a designer that produces XML rather than one that holds state.

The package scripts are just two, dev runs vite and build runs vite build, and there is no test script, no lint script and no library build. The package name is bpmn-vue-aciviti, at version 0.0.0, and it is not marked private, so the manifest is a template rather than a published library. There is a yarn.lock rather than a package-lock, and the vite configuration and tsconfig are at the root alongside the source, with an index.html and a public directory, and a gh-pages-deploy.sh script for publishing the built site to GitHub Pages.

The Dockerfile confirms the shape of the artifact. It starts from nginx, copies the dist directory into the nginx html root and the nginx.conf into place, exposes port 80 and runs nginx in the foreground. The build step is a separate action, and the comments in the file show the two commands: build the image with a tag, then run it with a name, mapping a host port to 80 and detaching it. The nginx.conf at the repository root is the server configuration that goes with it.

The container definition is short enough to read in full:

FROM nginx
COPY dist/ /usr/share/nginx/html/
COPY nginx.conf /etc/nginx/nginx.conf

EXPOSE 80

CMD ["nginx", "-g", "daemon off;"]

The practical upshot is that what you deploy is a static site. The designer runs entirely in the browser, talks to the Activiti backend through whatever the application wires up, and serving it is a matter of putting a built directory behind a web server. There is no Node process in production and no application server to keep running, which is a genuinely small operational footprint for something that sits inside a business workflow tool.

The deployment story for the demo is GitHub Pages, which is the gh-pages-deploy.sh script and the .nojekyll file the repository root contains, and the live example the readme links is served from a GitHub Pages URL.

The project state, and the gap between this and the full stack

Some things to know before you build on this.

The repository publishes no GitHub releases, and the last push was on 2026-04-10, so there is no tagged version to depend on. The package version in the manifest is 0.0.0, which is the template default rather than a meaningful version number. If you fork this, you are tracking a branch.

The linked Vue 2 implementation by another author is also pointed at in the readme as a friendly link, which is useful context: the Vue 3 rewrite is a port of an existing Vue 2 designer, and the sibling project is a working reference for the same feature set on the older stack. The related citrus project, in a citrus-workflow branch, is where the Activiti 7 backend integration lives.

Two limitations are worth naming. The translation module in the configuration directory defines the BPMN related Chinese translations, so the interface is Chinese by default, and a team shipping it elsewhere would need to add translations. And the docs are thin, consisting of a README that is a directory guide and a live example, with no published API reference and no changelog, so the extension mechanism is learned by reading the configuration files rather than from documentation.

There is also a SECURITY.md at the repository root, which is a small positive sign for a project that will be deployed inside a business tool, and a Dockerfile plus nginx configuration that show the maintainer expected people to run this as a container rather than only on a developer machine.

The honest summary is that this is a well-shaped example of the data driven designer pattern, in a stack that is current for Vue work, with the pieces that a product team would need to finish, such as translations and documentation, still to do.

Editorial conclusion

Adopt bpmn-vue-activiti if you model Activiti processes and want a designer you can extend by editing configuration files rather than by writing Vue components, and if your frontend stack is already Vue 3 with Element Plus. Do not adopt it as a backend, since the Activiti 7 integration lives in a separate repository, and do not expect a documented public API, because the readme describes the extension mechanism rather than a stable contract. Before you commit, read the config/modules directory to see how a node type is described, and plan for the fact that the last push was on 2026-04-10 with no published releases.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Project website
4. README
5. Yiuman/bpmn-vue-activiti on GitHub