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)
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.
Rely on our Conventions
We generally use lowerCase service names that are equivalent to the UpperCase implementation:
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.
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.
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.