For the path to be accurate it needs to be calculated at the moment of op insert
not at commit. This is because the path may contain list indexes in parent
objects that could change by inserts and deletes later in the transaction.
The primary change was adding op_observer to the transaction object and
removing it from commit options. The beginnings of a wasm level
`applyPatch` system is laid out here.
In an attempt to make our package naming more understandable we move all
our packages to a single NPM scope. `automerge` ->
`@automerge/automerge` and `automerge-wasm` ->
@automerge/automerge-wasm`
By moving to wasm-bindgens `bundler` target rather than using the `web`
target we remove the need for an async initialization step on the
automerge-wasm package. This means that the automerge-js package can now
depend directly on automerge-wasm and perform initialization itself,
thus making automerge-js a drop in replacement for the `automerge` JS
package (hopefully).
We bump the versions of automerge-wasm
The colunar storage format allows for values which we do not know the
type of. In order that we can handle these types in a forward compatible
way we add ScalarValue::Unknown.
Signed-off-by: Alex Good <alex@memoryandthought.me>
Weave the original TypeScript code into the C ports of the WASM API's
sync tests.
Fix misnomers in the WASM API's basic and sync unit tests.
Fix misspellings in the WASM API's basic and sync unit tests.
I'm not sure if there are some configurations under which this works,
but I get
index.d.ts:2:21 - error TS1005: ';' expected.
2 export default from "automerge-types"
~~~~~~~~~~~~~~~~~
both in my project that depends on `automerge-wasm` and when I run `tsc`
in this repo.
It seems like `export default from` is still a Stage 1 proposal, so I
wouldn't expect it to be supported by TS, although I couldn't really
find hard evidence one way or the other. It does seem like this syntax
should be exactly equivalent based on the proposal doc though.
