Tech: migrate to es version of lodash (and shows dist size stats)

[ndelangen]

No description provided.

[ndelangen]

OK this makes sense.. the reason tree-shaking barely seems to work is because of this:

storybook/code/ui/manager/src/globals/runtime.ts

Lines 4 to 10 in 43f93bb

	import * as STORYBOOKCOMPONENTS from '@storybook/components';
	import * as STORYBOOKCHANNELS from '@storybook/channels';
	import * as STORYBOOKEVENTS from '@storybook/core-events';
	import * as STORYBOOKROUTER from '@storybook/router';
	import * as STORYBOOKTHEMING from '@storybook/theming';
	import * as STORYBOOKMANAGERAPI from '@storybook/manager-api';
	import * as STORYBOOKCLIENTLOGGER from '@storybook/client-logger';

In short:
We prebundle the whole package, to then expose it to addons globally.
But we have no way of knowing what the addon might actually use, so we have to load the entire module, everything it exports.

I tested this by adding:

// code/lib/manager-api/src/index.tsx
export const THIS_IS_A_TREESHAKING_TEST = true;

Which is then never ever used anywhere...

But it's still preserved in the manager prebundled code, because.. we load it as a import * as X..

So.. to get smaller prebundles, we need to limit our public API.

[ndelangen]

This depends on this: ComponentDriven/csf#62 getting merged.

[valentinpalkovic]

If we alias all occurrences of lodash to lodash-es, we have to also make sure, that lodash-es is installed for every package. Does the aliasing also encounter for lodash usage in node_modules? If so, how can we even be sure, that the right version of lodash-es is installed instead? Can you explain this part to me. I am a bit confused.

[ndelangen]

we have to also make sure, that lodash-es is installed for every package

yes

Does the aliasing also encounter for lodash usage in node_modules?

Sort of, when the bundler is following the modules-graph up, it will encounter imports to lodash and swap it out.
However when it encounters a module that's external, it will skip, and leave the import as-is.

This means if package-a depends on lodash, but package-a is externalized, it will NOT be swapped.

[valentinpalkovic]

Why do we need this plugin? Is tree-shaking not correctly working for lodash-es? Or do we want to accommodate all lodash usages, which we haven't swapped out by lodash-es?

[valentinpalkovic]

I don't understand this. Can you explain it to me?