You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
bpmn-visualization follows the TypeScript evolution and the dependency is often updated to use the latest available version.
So in the code, we introduce the usage of new TS features. For instance
The new TS keywords or types can then be present in the type definition files that are included in the npm package which TS forces project integrating bpmn-visualization to use a compatible version of TS.
For instance, in bpmn-visualization@0.26.1, the BpmnVisualization class declare an import with both a type and a value
This means that the minimum version of TS to use for integration is at least version 4.5 (a newest version may be needed, the analysis is not complete here).
We don't document this requirement and we don't even know what the minimal TS version is as we don't test it. We have example projects that use TS but they also use the latest available version, so they cannot be used to detect it.
That's why we discover that users are stuck like in #2221 and must use an old bpmn-visualization version.
Notice that these projects are not using all bpmn-visualization API so they may not detect some type issues.
Proposal
I propose that we detect what is the minimal TS needed to use bpmn-visualization and that we document it. Remember that bpmn-visualization also depends on typed-mxgraph that has its own TS requirement. Currently, bpmn-visualization@0.26.1 depends on typed-mxgraph@1.0.7 which depends on TypeScript 4.1.3.
By documenting, I mean this must be explicit and if possible, usage of an old version should produce an error in the projects integrating bpmn-visualization. Just documenting it in the README won't be enough.
We should also have clear policies about TS bump requirements and we should communicate at least about it in the release notes when it appears. This may not be related to the TypeScript version bump, just to the new TypeScript features we use.
Macro tasks
Detect the lowest TS version
[2022-09-16] It is TS 4.5 for bpmn-visualization@0.26.1
Automatic tests
Once we know the version, we should add automatic tests that ensure that we don't need a more recent version. We could check DefinitivelyType for inspiration.
We could create a TS project on the fly and check TS compilation (this was done like this in Jest prior v26) or with a static project within the bpmn-visualization repository:
We could run the automatic check in the workflow that produces the npm package: the project needs types stored in the npm package, so we could run the test after the package artifact upload.
tbouffard
changed the title
[DOC] Document the minimal TypeScript version needed to use bpmn-visualization
[DOC] Document the lowest TypeScript version needed to use bpmn-visualization
Sep 16, 2022
tbouffard
changed the title
[DOC] Document the lowest TypeScript version needed to use bpmn-visualization
[DOC] Document the lowest TypeScript version supported by bpmn-visualization
Sep 16, 2022
Current situation
bpmn-visualization
follows the TypeScript evolution and the dependency is often updated to use the latest available version.So in the code, we introduce the usage of new TS features. For instance
bpmn-visuailzation@0.17.1
, see [REFACTOR] Make override methods explicit #1415bpmn-visuailzation@0.21.0
, see [REFACTOR] Explicit mxgraph type imports #1666The new TS keywords or types can then be present in the type definition files that are included in the npm package which TS forces project integrating bpmn-visualization to use a compatible version of TS.
For instance, in bpmn-visualization@0.26.1, the
BpmnVisualization
class declare an import with both a type and a valueThe resulting import in the definition file looks like:
This means that the minimum version of TS to use for integration is at least version 4.5 (a newest version may be needed, the analysis is not complete here).
We don't document this requirement and we don't even know what the minimal TS version is as we don't test it. We have example projects that use TS but they also use the latest available version, so they cannot be used to detect it.
That's why we discover that users are stuck like in #2221 and must use an old bpmn-visualization version.
What we know today
Notice that these projects are not using all bpmn-visualization API so they may not detect some type issues.
Proposal
I propose that we detect what is the minimal TS needed to use bpmn-visualization and that we document it. Remember that bpmn-visualization also depends on
typed-mxgraph
that has its own TS requirement. Currently, bpmn-visualization@0.26.1 depends on typed-mxgraph@1.0.7 which depends on TypeScript 4.1.3.By documenting, I mean this must be explicit and if possible, usage of an old version should produce an error in the projects integrating bpmn-visualization. Just documenting it in the README won't be enough.
We should also have clear policies about TS bump requirements and we should communicate at least about it in the release notes when it appears. This may not be related to the TypeScript version bump, just to the new TypeScript features we use.
Macro tasks
Detect the lowest TS version
[2022-09-16] It is TS 4.5 for bpmn-visualization@0.26.1
Declare the lowest TS version
typesVersions
field in package.json: https://www.typescriptlang.org/docs/handbook/declaration-files/publishing.html#version-selection-with-typesversions, starting from TS 3.1<3.4
support sindresorhus/execa#336Automatic tests
Once we know the version, we should add automatic tests that ensure that we don't need a more recent version. We could check DefinitivelyType for inspiration.
We could create a TS project on the fly and check TS compilation (this was done like this in Jest prior v26) or with a static project within the bpmn-visualization repository:
We could run the automatic check in the workflow that produces the npm package: the project needs types stored in the npm package, so we could run the test after the package artifact upload.
Tasks
The text was updated successfully, but these errors were encountered: