What development setup do you use?

Developers Modeler
1

Hi, it’s friday and I thought this might be an OK-moment for a more general question for people currently developing bpmn-io or camunda modeler related code. (And I’m currently not too happy about my setup, so I’m looking for ideas)

I thought I go first:

  • What I’m working on: An extension for Camunda Modeler
  • To write my code I use Visual Studio Code (on a linux machine)
  • I started with cloning the example plugin and added all my code there
  • For version control I use a Gitlab installation from my university. (I promise to move the code to something more public when it’s in a better shape)
  • I read a lot of the original diagram-js and bpmn-js code to understand what I can use in my extension. For reading the code I use Atom on a second screen

What I don’t like about my setup:

  • I have no autocompletion for the ‘objects’ I inject from the original framework. So in order to know what properties and functions I can use, I print the objects to the console in the Modeler and go through the available functions, as this i faster than scrolling through the original code. (I think I should use some symbol map in Atom. That could help.) This seems a bit strange and unergonomic to me.

So maybe you care to share your environment. It could be very helpful for others.

1 Like
2

Let’s talk about the things you don’t like:

Since JavaScript is dynamically typed (strongly typed at run-time only) editors cannot give easy assistance to you regarding type information. Because of that it can be hard for newcomers to jump into our code base. A few things may help you though and speed up the discovery process.

Rely on our Conventions

We generally use lowerCase service names that are equivalent to the UpperCase implementation:

export function Logger(eventBus) {
  ...
}

Logger.$inject = [ 'eventBus' ];

Use your development environment to search for EventBus to quickly jump to the implementation.

Ensure you got both, bpmn-js and diagram-js on your search path. Know your search shortcuts (CTRL + P in Sublime Text) and you can pretty much find all implementations instantly.

Use the JavaScript Debugger

Put a debugger statement in your code and inspect the program at run-time or during a test run using the Chrome Dev Tools (use F12 to toggle them in Chromium).

The Dev Tools are available in the Camunda Modeler during development (npm run dev) via the same shortcut, too.

The debugger is a largely underrated but massively important tool to understand code bases in dynamically typed languages. It will surely help you out understanding our tools, too.

Write Tests

Our toolkits are built with great testability in mind and I would strongly encourage you to exploit that.
It is close to trivial to write test cases that assert whatever you build is correct. Tests serve another important use case, too: They are anchors to jump into the program execution, set conditional debugger statements and explore what is going on. My experience is that they boost understanding of unknown and complex code bases a lot.

Running a single test focused (i.e. via mochas it.only) will give you a visual, interactive representation of what you’re building. You may even run existing tests using it.only to understand what is going on under the hood.

Build a bpmn-js Plugin first

It is much easier to build and test a bpmn-js plugin and integrate it into the Camunda Modeler later than starting to fiddle around with the Camunda Modeler from the start. Integrating whatever functional plugin you got into the Modeler is not too hard.

An example for this is how bpmn-js-token-simulation got built and later integrated as a plug-in.

3

I’ve added a section on testing to my previous comment, as I believe this is generally underrated and hugely beneficial, too.