Framework: Add babel-plugin-lodash to enable root Lodash imports

[aduth]

Related: #3015, #735

This pull request seeks to include babel-plugin-lodash in our Babel configuration to allow for root Lodash imports without worrying about unnecessarily bloating the size of resulting bundles.

Before / After reflects build without Babel plugin, then build with plugin and sites selectors dependency revisions (4995c88).

Before	After

Testing instructions:

May be worth having a second set of eyes on before/after build sizes to confirm that no bundle bloating occurs. Verify that no regressions occur in usage of application (sites selectors are pretty pervasive through the app, notably My Sites section).

Test live: https://calypso.live/?branch=add/babel-plugin-lodash

[nylen]

LGTM. I would update npm-shrinkwrap.json to only contain the changes related to this PR - I did this in #6543 - but then I noticed that nothing in our shrinkwrap documentation would prevent a full update. Thoughts on which approach is preferred? It seems desirable to avoid potential breakage from changing versions of sub-dependencies.

[aduth]

I would update npm-shrinkwrap.json to only contain the changes related to this PR

Generally, I'd agree that including unrelated changes should be avoided. That said, I think it's been more-or-less standard practice that producing a new shrinkwrap will include any version bumps of dependency "grandchildren" (dependency dependencies). Two reasons I see are:

• We otherwise don't have a process for upgrading these packages
• It's not always straight-forward which package updates are related to the targeted package being installed (Framework: Update ESLint configuration to extend shared config #6543 is easy because eslint-config-wpcalypso has no dependencies of its own).

I think this has come up at least once before recently, so whichever process we adopt, I think it'd be good to document in our shrinkwrap docs (cc @gwwar ).

[gwwar]

I think this has come up at least once before recently, so whichever process we adopt, I think it'd be good to document in our shrinkwrap docs

I'll spin up a PR to update docs. I think it's OK to have sub sub dependencies update. We pick up bug fixes, and these new package versions get tested a bit in the PR. In addition to this, npm 3 tries to create an "ideal" flat tree, so this may mean that we can have a smaller shrinkwrap file if multiple packages happen to use the same sub dependency versions.