Remove general lodash require?

[aaronjensen]

As mentioned in #136, lodash is required and included globally for use within examples. I personally don't use this and don't care to pay the 100kb+ price in size and load time. Would it be possible to make this optional or just not include it and let people require what they want in examples?

Is there currently a hook to add globals like this? If so, I'd probably like to use it for a few other things.

• Find working solution to provide context modules.
• Replace global React/Lodash with it.
• Add an option to easily add globals.
• Remove Lodash at all.
• Update docs.

[sapegin]

Probably it‘s a good idea. But probably current way to optionally enable it is a bit too complicated. You need to add a JS file to entries like this:

globals._ = require('lodash');

[sapegin]

But probably we can use webpack.DefinePlugin or webpack.ProvidePlugin for that and make an easy config option like that:

globals: {
  _: require('lodash'),
}

I’d use that too! Not sure that globals is the best name.

[sapegin]

But don’t compare ungzipped sizes, they are not that important ;-)

[aaronjensen]

I've never used webpack.DefinePlugin for anything but constants, but maybe that'd work. I think the entries is more straight forward. It's what I'm doing today for some other stuff.

ungzipped sizes are important for runtime afaik. The more code that's there, gzipped or not, the more it needs to execute which will slow startup.

[sapegin]

I think it should be webpack.ProvidePlugin : https://github.com/madewithlove/webpack-config/blob/fcf39f3b31378b59f31c3353f6973801a5f53e8e/src/plugins/provide.js

[aaronjensen]

I'm not sure that will work for the case we want. It doesn't actually set them globally, it makes them available as free variables w/in modules, which our examples are not.

[sapegin]

Looks like it works fine. I’ve added a todo list to the issue. Do you want to work on that?

[oliverturner]

An alternative would be to use babel-plugin-lodash to automate the module extraction: possibly less onerous.

[sapegin]

We can’t use Babel for user’s code and especially for examples. Styleguidist itself already use crerry-picking everywhere.

[oliverturner]

got it: good catch :)

[aaronjensen]

@sapegin 4ae9927 doesn't work at all for me:

[sapegin]

Very strange. Why does it work for me then? ;-}

[aaronjensen]

I'm guessing because of the new build step. If you didn't compile after making the change it'd still look like it works.

I think that what we actually want to do is add React to the execution context. I've not yet wrapped my head around the way that it all works, but that'd be the best imo. That way we wouldn't pollute the global namespace.

Furthermore, the config option to add "globals" should maybe be called context and add those things to the context as well rather than globally:

context: {
  _: 'lodash',
  foo: 'foo',
}

[sapegin]

You're genius! I forgot to start the compiler 🐙

And I agree on both points: about context and about the name.

[sapegin]

Before:

❯ gz examples/basic/styleguide/build/bundle.js
Original: 2.35 MB
Gzipped:  499 kB (21.29%)

After:

❯ gz examples/basic/styleguide/build/bundle.js
Original: 1.81 MB
Gzipped:  403 kB (22.31%)

Almost 100 KB difference gzipped!

[sapegin]

And with fixed UglifyJS (and with proper name mangling options):

❯ gz examples/basic/styleguide/build/bundle.js
Original: 631 kB
Gzipped:  183 kB (29.02%)

[aaronjensen]

Very nice!