Open achingbrain opened 4 months ago
One spanner in the works here is that this module uses an older, incompatible version of JavaScript decorators so updating TypeScript is quite painful.
The decorators just add saveAsJSON
/fromJSON
methods to the filters. Is it necessary to use decorators for this? Could they just be regular methods instead?
Hello 🖖 I'm working on a 4.0.0-alpha.0 available here https://github.com/Callidon/bloom-filters/tree/next/4.0.0. What's new in this version?
@node-rs/xxhash
instead of xxhashjs
. A very good implementation and a very good boost in performance. Plus! It uses WASM when bundled in a browser 👍 lodash
packages to import only specific ones with lodash.xxxx
..mts
but compiled as .mjs
rspack
and webpack
eslint
is now very strict, it extends: @typescript-eslint/strict-type-checked
jest
instead of mocha
; remove all describe
to be able to use beforeAll
/beforeEach
if necessaryHashing
class in a static variable called lib which only exports xxh32
and xxh64
so that the functions are available everywhere by calling this._hashing.lib.xxh[32/64]
or Hashing.lib.xxh[32/64]
yarn@berry
tsc
rspack
bundlewebpack
bundleprettier
eslint
jest
fromJSON
and saveAsJSON
functions in the different classes. I would also like to remove the long
and buffer
dependencies, so if want to help you are welcome to create a PR from this new branch.
Let me get a stable state before going on! I need to fix the tests. With the new xxhash package I introduced good bugs dealing with bigints. This will prepare the work for the long package.
Update: buffer and long are not used anymore. The draft https://github.com/Callidon/bloom-filters/pull/71 is in progress but is working as expected. Take a look, I will be happy to get feedback, especially on the usage of the wasm which takes around 347kb 😬
I'd really like to use this module in browsers but the bundle size ends up being very large, just importing the
CuckooFilter
adds over 50KB of minified code to the bundle.Using
esbuild
to bundle just this script:Creates a 216KB bundle (63KB minified), and I have to shim some node internals (e.g. the
Buffer
class) for it to work:The
CuckooFilter
implementation itself is 8.4KB un-minified so there's a lot of unused code here.Would you be open to some PRs that make this module more browser friendly?
Some low hanging fruit I can see immediately:
Buffer
s with built-inUint8Array
slong
dependency and use built-inBigInt
sThe first is a breaking change but will yield the biggest benefit - the breaking change is that consumers will no longer be able to
require
the module, they mustimport
it via static or dynamic imports.The second is breaking where
Buffer
s are used as return values which from what I can see only appears to be in the Invertible Bloom Lookup Table implementation.The rest are just internal changes so are non-breaking.