Add ad-hoc subprocess

[jarekdanielak]

Proposed Changes

Add ad-hoc subprocess to menu options and update dependencies.

Related to camunda/camunda-modeler#4739

Checklist

To ensure you provided everything we need to look at your PR:

• Brief textual description of the changes present
• Visual demo attached
• Steps to try out present, i.e. using the @bpmn-io/sr tool
• Related issue linked via Closes {LINK_TO_ISSUE} or Related to {LINK_TO_ISSUE}

[jarekdanielak]

The failing test wants Transaction to be the first replace option on an element with transaction template. Do we mind if it's not the first, but just check if it exists in the menu?

[philippfromme]

The failing test wants Transaction to be the first replace option on an element with transaction template. Do we mind if it's not the first, but just check if it exists in the menu?

I guess we just need to adjust the test case. The order is kind of random. I'd expect the transaction to be the last option after all the *-subprocess options.

[jarekdanielak]

Based on RemoveTemplateReplaceProvider#addPlainElementEntry, the "remove template" option goes where a plain element would be. It's not fixed to go to the 0th index.

[jarekdanielak]

I think just expecting the plain element to be available in the menu is a viable strategy. (9d237e7)

[barmac]

It's weird that the entries seem to be in correct order before rendering:

[barmac]

Looks that Object.entries does not respect the object ordering:

So it behaves more like a hashmap or a dictionary in Python.

[barmac]

But it's supposed to be the same as in for..in loop: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/entries#description

[barmac]

OK so the debugger prints something different than the javascript evaluates to:

[philippfromme]

How should we go about this? Merge and fix the order later?

[philippfromme]

I will create a follow-up issue for the order.

[barmac]

I think this is OK.

[barmac]

@philippfromme I think this problem was caused by a bug in the library. We use "previous option index" to place the remove template action after it. However, if the desired option is at index 1, the previous option is placed at index 0. This is falsy and causes the condition to not be met in the code when it should be.

[barmac]

So the bug must have existed before, but we did not have a test to reproduce it.