Fix JSDoc types for services

[nikku]

What should we do?

Our existing JSDoc type definitions on services are built in a way that makes it impossible for IDEs to use, cf. Canvas for example:

/**
 * The main drawing canvas.
 *
 * @class
 * @constructor
 *
 * @emits Canvas#canvas.init
 *
 * @param {Object} config
 * @param {EventBus} eventBus
 * @param {GraphicsFactory} graphicsFactory
 * @param {ElementRegistry} elementRegistry
 */
function Canvas(....) {

Fixing these types by pointing to the actual implementations allows us to TypeScript type hinting to find potential miss-use:

/** @typedef { { container?: DOMElement, ... } } CanvasConfig */

/**
 * The main drawing canvas.
 *
 * @class
 * @constructor
 *
 * @emits Canvas#canvas.init
 *
 * @param {CanvasConfig} config
 * @param {import('./EventBus')} eventBus
 * @param {import('./GraphicsFactory')} graphicsFactory
 * @param {import('./ElementRegistry')} elementRegistry
 */
function Canvas(....) {

Coming up with a way to automagically fix these would be another improvement, as we got the same issue in bpmn-js and our other toolkits, too.

Related, but not necessarily similar we should fix type definitions on service APIs.

Related, and likely required, we should integrate type linting tsc --pretty into the build.

Why should we do it?

This improves the editing experience for new contributors, allows for jump to definition on public APIs and so on.

---

Child of bpmn-io/bpmn-js#1002

[philippfromme]

Closed by https://github.com/bpmn-io/internal-docs/issues/688. diagram-js@12 includes type declarations.