The vite built complained about an invalid "paths" settings in the root
tsconfig.json file.
It wasn't nested inside a "compilerOptions", so it was useless and this
configuration has been removed.
Previously, codec classes were defined and registered in the same file
as the class they targeted. This prevented efficient tree-shaking: as
soon as the target class was imported (e.g. `StyleSheet`), the
corresponding codec was also imported (`StyleSheetCodec`). As a result,
a large amount of codec code (and dependent code) was present in
applications incorporating maxGraph, even if they didn't use the codec
function. As there are currently many problems with the codec function
that make it almost unusable, this was a great waste.
Codecs are no longer registered by default, which reduces side effects
and coupling.
It also greatly improves tree-shaking.
For example, in the `ts-example` application included in this repository
which doesn't use the "codec" feature, the size of the minified
`maxGraph` chunk goes from `568.58 kB` to `467.90 kB`, which corresponds
to a size reduction of `17.7%`!
BREAKING CHANGE: Codecs supplied by `maxGraph` are no longer registered
by default. They MUST be registered before performing an `encode` or
`decode`. You can use one of the following functions to register codecs:
- `registerAllCodecs`
- `registerCoreCodecs`
- `registerEditorCodecs`
`maxGraph` was using `lerna` v4 to build and only used its "build
workspaces" support, not the "publishing" support as we only published a
single package and it is done manually, without using `lerna`.
The support for packages in `lerna` was removed in version 7. See
https://github.com/lerna/lerna/releases/tag/7.0.0 and
https://lerna.js.org/docs/legacy-package-management.
So, start using npm workspaces as we don't need to manage the publishing
of several packages for now.
This will allow to do more reproducible builds by locking dependencies
with a `package-lock.json` file. This didn't work well with `lerna` v4
and had been disabled.
Replicate the improvements done in the `maxgraph-integration-examples`
repository:
- introduce function to simplify the main file
- Remove out dated comments
- Simplify the code and use "type" imports when possible
Providing these resources simplify the `maxGraph` integration.
Use the default CSS in ts-example to illustrate how to override defaults
Initiate a documentation to start guiding users.
ts-example
- improve the position of the ellipse labels
- introduce a shared style for ellipse vertices
- bump vite from 4.3.9 to 4.4.2
- work when not deployed in the "root" context of the site
README
- improve the position of the ellipse label
- display rounded orthogonal edge
- fix the style configuration to match the rendering shown in the gif
The methods defined in the `EdgeMixin` type were not documented.
The signature of the `insertEdge` method was using a spread `any`
parameter, so it provided no guidance nor guard.
Instead, the type now declares the various form of the methods with the
right signature.
The methods defined in the `VertexMixin` type were not documented.
The signature of the `insertVertex` method was using a spread `any`
parameter, so it provided no guidance nor guard.
Instead, the type now declares the various form of the methods with the
right signature.
These 2 classes were previously not exported as they generated runtime
errors when applications integrating `maxGraph` used the Vite dev
server.
Bump vite from 4.3.1 to 4.3.9. This is probably what fixed the problem.
No need to export Stylesheet and EditorToolbar as default as they are
already exported.
The default edge and vertex styles are always defined. Updating the
signature of the two methods returning default styles simplifies the
code for callers, who don't have to deal with "undefined" values.
Improve the ts-example
- rely on no `undefined` style
- bump vite from 3.2.3 to 4.3.1 and increase the file size warning
- improve the use of types
- better explain why we cannot use enum to define the 'edgeStyle'
CellStyle property
BREAKING CHANGE: `Stylesheet.getDefaultVertexStyle` and
`Stylesheet.getDefaultEdgeStyle` no longer return `undefined`.
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).
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.
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).