Requiring slug with browserify includes a 1.8MB file

[jshakes]

After some investigation into why my Browserify output file was so huge, I found the unicode dependency in package.json (https://www.npmjs.com/package/unicode) contains a 1.8MB file called So.js. How important is this file, and is there any way we can do without it? I can't continue using slug for my front-end application if it means doubling the footprint of my Browserify file

[ralyodio]

just curious, why are you generating slugs on the client side?

[jshakes]

In my case I'm just using it to make an HTML attribute value from a string,
but there are many cases where we use slug generation on the front-end,
including here on Github

[ralyodio]

i would make an endpoint you can call.

[jshakes]

With all due respect, that's besides the point. Nowadays npm packages are increasingly being used isomorphically, especially with platforms like Meteor.

For a precedent, see the node-slug npm package which provides a flag specifically for this scenario: https://github.com/dodo/node-slug#browser

[ralyodio]

with all due respect just because they can be used isomorphically doesn't mean they should be used that way.

[michaelfavia]

FWIW We were bit by this same issue it tripled the size of our clientside webpacked bundle. To be fair we discovered your module as a result of our previous routing work on the backend but the 1.8mb payload was a bit of a surprise. Replaced with https://github.com/pid/speakingurl

[Zertz]

You can use const slug = require('slug/slug-browser') and add exclude: ['node_modules/unicode/category/So.js'] to Browserify's options.

We also use slugs client-side because it's far faster then calling an endpoint just to give the user a quick preview and the minified code is tiny.

[barbalex]

I ran into the same problem too. @michaelfavia thanks for mentioning https://github.com/pid/speakingurl: 12.7KB vs. 1.7MB!!!