Consider moving away from assert for code that runs in the browser

[christiango]

The assert library is a native node API that has a client side equivalent that Fluid has been taking a dependency on: https://github.com/browserify/commonjs-assert

The library itself is quite small, but it does pull in a lot of dependencies. Specifically it pulls in these dependencies:

    "es6-object-assign": "^1.1.0",
    "is-nan": "^1.2.1",
    "object-is": "^1.0.1",
    "util": "^0.12.0"

I did a demo where I modified the webpack config in examples/collaborative-textarea

        resolve: {
            extensions: [".ts", ".tsx", ".js"],
            alias: {
                "assert": path.resolve(__dirname, 'assert.js')
            }
        },

Where assert.js is a js file in the root of the package with this definition

export function strict() {
}

This took the bundle down by 7KB gzipped and 24KB uncompressed.

Can we instead write a lightweight isomorphic library that provides the same functionality?

[christiango]

The bundle size impact appears even worse in Webpack 5, since it ends up pulling in assert v2 (respecting the package.json of FF), where v4 was including assert 1.5

Webpack bundle analyzer isn't fully compatible with WP5, so it is hard to get exact numbers, but it seems the impact of assert is about 55KB uncompressed

[SamBroner]

This isn't an immediate priority. We're using assert pretty widely. The assert package is pretty commonly used.

[christiango]

@SamBroner - I think we should make it a priority since it is about >15% of Fluid's bundle size. I don't think it's that commonly used in browser code.

I'll take this on myself since I don't think anyone else is looking at bundle size improvements to improve perf

[SamBroner]

Oh, great. If you do it, that'd be awesome!

Is there a better OSS assert package? I'd rather not be on the hook for maintenance or code complexity. Reimplementing assert is probably not the hard part.

[christiango]

We only really need a very simple thing, which I've already proposed in #4108. No need to pull in a dependency for our use case here