By using a custom orbit-db store I ran into an issue that I noticed also while developing ipfs-boards.
In chlu-ipfs we transpile sources with babel, and the ChluStore class (wrote by us, extends orbit-db-store's Store class) gets transpiled as well. Then, in chlu-demo and chlu-explorer we load the transpile sources but OrbitDB is loaded from node_modules, so OrbitDB is not transpiled, and is loaded as ES6 code.
From babel transpiled sources you can't extend a native ES6 class (see refs below), because at runtime they are different. You either transpile both or neither.
If we load the real sources instead (I tried using require('chlu-ipfs-support/src') both the classes will be ES6 classes and it will work in development. In the production build, they will both be ES5 transpiled code and it will also work.
We might be forced to stop
By using a custom orbit-db store I ran into an issue that I noticed also while developing ipfs-boards.
In chlu-ipfs we transpile sources with babel, and the ChluStore class (wrote by us, extends orbit-db-store's Store class) gets transpiled as well. Then, in chlu-demo and chlu-explorer we load the transpile sources but OrbitDB is loaded from node_modules, so OrbitDB is not transpiled, and is loaded as ES6 code.
From babel transpiled sources you can't extend a native ES6 class (see refs below), because at runtime they are different. You either transpile both or neither.
If we load the real sources instead (I tried using
require('chlu-ipfs-support/src')both the classes will be ES6 classes and it will work in development. In the production build, they will both be ES5 transpiled code and it will also work.Refs: