We use a recent TypeScript version to build maxGraph but applications
that integrates it may be forced to use old TypeScript versions.
We never explain what is the minimum TypeScript version requires to use
`maxGraph`. The changes proposed here are a first step to make this
information available.
It is only informative for now (mentioned in the README) and the minimum
TypeScript version is tested in the `ts-support` package (part of the
'build' GitHub workflow).
When running `generate-types` script in core package
there is typescript error TS2345 in src/util/Dictionary.ts,
added changes to fix it.
- Moved types IdentityObject and IdentityFunction to types.ts
- Renamed const FIELD_NAME to IDENTITY_FIELD_NAME and
moved it to util/Constants.ts
- Set Cell and CellOverlay to implement IdentityObject
bump vite from 2.9.12 to 3.1.0
add vite config to generate a dedicated chunk for maxgraph@core. It lets know the size the produced bundle in an
external application and if tree shaking works.
Remove unused static properties
- mxForceIncludes: it was used to force loading the JavaScript files in development mode in mxGraph. We are not managing development mode in that way anymore.
- mxLoadResource: not used anymore
- mxLoadStylesheets: not used anymore
- mxResourceExtension: it was only used in Translations, so only keep the Translations settings
Move and rename the link function. It is not a general function, so move it as `domUtils#addLinkToHead`
Fix documentation of static properties
Root and all package.json files
- Fix license, version and authors
- Remove the non-relevant .npmignore file at the project. It was designed for mxgraph, the whole directory structure
changed, and we don't plan to publish the root package
`core` package
- Generate type definition and javascript files for ESM output
- dedicated folder for `esm` and `types` in the `dist` folder to clearly separate concerns
- exported in the package.json
- Add npm script for `npm pack` configuration
- Drop the `postinstall` npm script that built the `core` bundle. It would have been run when the package is installed
in dependent projects at dependencies install. And it would have failed as it tries to build the project from TypeScript
sources that are not available in the npm package.
fix: ConstraintHandler now loads image as everywhere else in the code using `Client.imageBasePath`
Using import doesn't work as the image is not available in the npm package. It generated error like this in ViteJS
project:
Failed to resolve import "../../../images/point.gif" from "../core/dist/esm/view/handler/ConstraintHandler.js". Does the file exist?
This gif import had been introduced to make `Anchors.stories.js` retrieve the gif file. Configuring `imageBasePath` as
already done in other stories fixes the issue.
Don't export EditorCodec and StylesheetCodec as they generate errors.
This is a temporary solution to avoid error in dependent project (at least, with ViteJS projects).
This ensures we don't have type errors in the code.
Update tsconfig to only include source TS files.
Previous configuration prevented to run the type generation twice.
The generated d.ts files were considered as source files, so we got file override errors.
Add a dedicated npm script to generate scripts.
We cannot directly call the tsc or lerna commands on the macOS GH actions runner, so introduce the script.
This replicates what mxgraph examples previously provided: the source code directly accessible within the example.
It allows copy/paste for reuse in user applications and should improve the adoption.
The code used to manage the controls is easily identifiable and can help highlight certain parts of the example (ContextMenu, RubberBand, ...).
Also bump storybook from 6.4.0 to 6.4.13.
Remove the extra NODE_OPTIONS in storybook server start script that generated an
error.
Remove cross-env devDependency which is then not used anymore.
Fix storybook deprecation warning (static dirs)
Fix imports that are not respecting the case of the filenames.
The build often has errors and they are only detected after a developer pull the `development` branch on their local machine.
To early catch build failures, add a GitHub workflow that runs a build command.
* reorganised directories; removed mx prefix
* reduced directory hierarchies; removed mx prefix; type fixes
* convert remaining javascript to ts
* fix/add types
* add type defs
* type updates; moved codecs to where they're used
* reorganise constants into enums+type additions
* removed "Function:" and "Variable:" prefixes from comments, as they aren't needed in JSDoc
* removed "Function:", "Variable:" and "Class:" prefixes from comments, as they aren't needed in JSDoc
* removed "Function:" prefixes from comments, as they aren't needed in JSDoc
* minor changes
* convert code example blocks to markdown
* module casing updates
* converted parameter function documentation to JSDoc
* documentation+type updates
* removed react subdir (for now)
* reorganised various `utils` functions into different files
* type updates/bugfixes/workarounds
* rename Rubberband and CellEditor to be *Handler to match the other plugins
* move codec classes to where they're used to reduce cyclic dependencies
* move codec classes to where they're used to reduce cyclic dependencies
* type updates/reorganize layout file structure
* renamed various files for consistency
* import fixes
* renamed GraphHandler SelectionHander and various fixes
* convert EventObject parameters to objects
* add basic better-docs config
* update better-docs config
* bugfix for shared variables in Graph persisting across instances
* fixed accessing handlers in examples; renamed Model to GraphModel
* fixed accessing handlers in examples; renamed Model to GraphModel
* restored selection model
* bugfix
* renamed getModel to getDataModel
* changed to use graph.batchUpdate() to reduce lines of code
* changed to use graph.batchUpdate() to reduce lines of code
* finished annotations+added TypeDoc
* convert remaining Cell[] instances to CellArray
* convert NaturalDocs links to JSDoc