Convert to lodash-es

[richgt]

Simple conversion from lodash to lodash-es. I did as little as possible to convert, leaving code in tact wherever possible by using imports to keep variable names the same.

[samselikoff]

I thought this PR from @ef4 already accomplished the size reduction? Is there any precedent in other addons for lodash vs. lodash-es?

[richgt]

@samselikoff - To be honest, I'm not sure about size reduction. I know that without the switch to lodash-es, we're not able to use mirage in our environment because we have issues with default exports (we've had to turn them off in loader.js because of our legacy test structure). If this conflicts with other things, I understand, and can probably just end up using a fork, but thought I'd send this through for you to take a look at.

This is the conflicting code in our environment that causes issues with the standard lodash that this update fixes for me:

// Disable generation of default exports, as this would otherwise modify the
// exports objects
loader.makeDefaultExport = false;

[samselikoff]

@ef4 I know you're busy so feel free to ignore, but wanted to see if you had any thoughts on default exports vs. named exports, and if a change like this would change the effect of #1561.

Alternatively, is there any way for us to shim the lodash default exports here so apps with makeDefaultExport = false can use Mirage? Or even something those apps themselves could do?

[ef4]

Instead of:

-import _assign from 'lodash/assign';
+import { assign as _assign } from 'lodash-es';

Try this:

-import _assign from 'lodash/assign';
+import _assign from 'lodash-es/assign';

I think that solves your problem.

makeDefaultExport = false doesn't mean you can't use any default exports (otherwise things like import Component from '@ember/component' also wouldn't work). It just means you can only get default exports from things that are authored as real ES modules. Switching to lodash-es gives you real modules, so the default exports work.

[samselikoff]

Gotcha 👍

So lodash-es seems like a good & modern approach for usage in Ember addons? Should I be using ember-lodash or are there any other considerations?

[ef4]

Ah, there is actually another gotcha now that you mention it. One that I happen to be working on fixing today.

At the moment we don't apply babel to things that are auto imported. That means that if there's any modern language features other than modules present in lodash-es, they would get served directly to browsers, which might not be what app authors want.

embroider-build/ember-auto-import#41

[samselikoff]

#1666 supersedes