Open jshakes opened 8 years ago
just curious, why are you generating slugs on the client side?
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
i would make an endpoint you can call.
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
with all due respect just because they can be used isomorphically doesn't mean they should be used that way.
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
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.
I ran into the same problem too. @michaelfavia thanks for mentioning https://github.com/pid/speakingurl: 12.7KB vs. 1.7MB!!!
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 calledSo.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