Immer: Idea: immer modern

[mweststrate]

Immer is quite large (4KB) if you compare it with the possible minimal implementation.

We could introduce an additional build or package that only targets modern browser and skip some of the lesser used features, making it ideal to bundle with packages that target modern bundles

• no ES 5 support
• no patches, hooks
• no custom configs?
• no polyfills / use modern browser features (for of, Array.of, etc etc)
• bundle ESM only?

Before doing that, probably should move to own org first (see #239)

[aleclarson]

Yeah, we better do it before someone else does. :P

Also, we should use Jest snapshots more when testing it. :)

[aleclarson]

Would it make sense for Immer 2.0 to be this?

[mweststrate]

No, I think the world is not ready yet for a proxy only library. And features like patch support are valuable in the future as well.

What we could do already do now, is to setup a separate compilation entry point, that doesn't include the ES5 implementation, and recommend people to setup (for example) node resolutions in package.json to build with the lighter version: "resolutions": { "immer": "immer/lite" }. That would easily fit in the current package, and enable quickly changing implementations if needed

[aleclarson]

@mweststrate I'm not too worried about the overhead of:

npm rm immer && npm install immer-lite :)

[mweststrate]

Me neither, but the advantage of resolutions is that it works for transitive deps as well. So libraries can always be written against the full immer, and then the hosting project can decide to use lite instead, instead of shipping with both. (this can of course be done with a separate package as well)

[ghost]

Also note that readme.md still says the gzipped size is 2KB but it is now 4KB as mentioned above.

[aleclarson]

@greydrizzle Updated. Thanks!

[scriby]

The world might not be ready for a proxy-only library, but I definitely am. I would imagine a lot of projects these days can get by without IE 11 support, which is pretty much the last holdout on proxy support.

[Aetet]

@mweststrate Would be great for 3.0 version

[mweststrate]

Note: this solution could work as well, and doesn't need a separate package
or separately maintained major:
https://twitter.com/mweststrate/status/1099030105815437312

On Sat, Mar 2, 2019 at 8:50 PM Max [e-mail] wrote:

@mweststrate https://github.com/mweststrate Would be great for 3.0
version

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/mweststrate/immer/issues/266#issuecomment-468953981,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABvGhAr13GR4DQS96ldNoy3LfJUZK8Ukks5vStYegaJpZM4ZRygs
.

[aleclarson]

@mweststrate You already mentioned that in this comment, unless I'm missing something. :)

[mweststrate]

I did a quick investigation, leaving out the the es5 implementation saves ~800 bytes (minified, gzipped). I think a little more can be gained by removing certain of the polyfills we use, like each, symbols,etc.

Although the reduction is relatively speaking roughly 20 - 25% of the lib, I don't think the absolute size reduction is worth the effort of complicating the build setup / duplicating code for now. If someone disagrees, PR is welcome that takes care of the build and test infra for that!