Audit npm dependencies

[thisandagain]

• Removed unused dependencies
• Find alternatives to modules which use native dependencies wherever possible
• Replace some dependencies with simpler local components
• Update (npm outdated) remaining modules

/cc @mewtaylor @rschamp

[hyperobject]

Things that should be removed:

• lodash.merge - Object.assign does effectively the same thing
• lodash.range - Using the ES2015 spread operator allows replication of this function in pure JS Here's what I've found so far:

Things that shouldn't be removed

• lodash.defaultsDeep - Object.assign is not recursive, and this is.
• lodash.defaults - Object.assign should behave in the same way, but due to a few quirks of Object.assign and lodash.defaults, removing this dependency is actually more work than it's worth, IMO.
• lodash.omit, lodash.clone - No easy workaround in vanilla ES6.
• xhr - Nice for cross-browser compatibility as well as working the same way in node.js and in the browser (for testing)
• react-modal - Redoing this would add unnecessary bloat to the codebase.
• google-libphonenumber, react-telephone-input - see react-modal

• formsy-react - The validation parts of formsy are useful enough that removing this doesn't make a lot of sense to me.

  Other:

• react-slick is not easily adaptable for mobile and is not ideal in terms of performance, but due to the current splash page design it has to stay. I have not found any good alternatives thus far.
• react-onclickoutside - the general concept isn't able to be replicated easily with built in JS features, but there may be a better package that does roughly the same thing (react-onclick-outside)
• keyMirror: Not really necessary, as the functionality can easily be replicated in vanilla JS (it just returns an object with the values being the same string as the key), but ergonomically it makes sense to keep.
• formsy-react-components would be nice to remove, since a lot of of the inputs provided by the package will need to be overridden anyway to implement the UX we want.

Most other packages in package.json are necessary for bundling and compilation.

[mewtaylor]

@technoboy10 thanks so much for this! Very helpful. Here're some thoughts:

• We should make separate issues for removing lodash.merge and lodash.range
• I think removing formsy-react-components and building our own version of elements using formsy-react makes sense. I think we eventually want some more fine-grained control over the UX of validation, which needs more granularity than using those components. Additionally, validation error rendering might become easier with more granularity. Perhaps we can make an issue for that and backlog it, since we also probably need to determine what our ideal UX for validation error rendering is.
• @technoboy10 I noticed that we only use the stylings from the slick-carousel dependency. Any idea if it would be easy to adapt that one and get rid of it?

Thoughts @rschamp @thisandagain ?

[rschamp]

@technoboy10 Thanks so much for going through this for us!

• lodash.defaults - Object.assign should behave in the same way, but due to a few quirks of Object.assign and lodash.defaults, removing this dependency is actually more work than it's worth, IMO.

Could you elaborate @technoboy10 — which quirks?

• google-libphonenumber, react-telephone-input - see react-modal

I fully agree about google-libphonenumber, however I think we probably could build react-telephone-input as our own component in order to eliminate a dependency. I used this component in the interest of time, but it left a bad taste in my mouth since I had to upgrade to React 15 in order for it to install, which made me have to upgrade a bunch of our other dependencies — that's the kind of silliness too many dependencies can cause.

+1 to building our own formsy-react components over using formsy-react-components. formsy-react-components expects you to build forms like you do in Bootstrap, but we aren't doing that. Not being able to change the order of help text, for example, is annoying.

On that note, formsy-react works pretty well for what we needed in the moment, but do you guys think it works in the ideal way? I like the way validation is configured for formsy-react inputs via props. However I don't like that it requires all inputs to be validated to be inside of a special formsy-react Form component (or that this component uses the poorly documented React context API). IMO the input should be able to handle validation by itself, even if it's not in a form. If you need to validate before submitting, or validate based on the values of different inputs, then that should be configurable via a higher order component. I didn't find anything that worked as flexibly as I'd like. I think there's still room for finding an alternative to formsy-react or building our own forms library. Or extending formsy-react to work this way and writing a convincing PR.

+1 also to replacing slick-carousel with our own component. I don't think the scope of what the component does is worth the overhead of the external dependency.

• react-onclickoutside - the general concept isn't able to be replicated easily with built in JS features, but there may be a better package that does roughly the same thing (react-onclick-outside)

I didn't realize we're still using this as a mixin — I tried to get rid of all of our uses of mixins. I think it'd be worth upgrading this package to the latest version which changes the API to work as a higher order component.

• keyMirror: Not really necessary, as the functionality can easily be replicated in vanilla JS (it just returns an object with the values being the same string as the key), but ergonomically it makes sense to keep.

Just for the record, the main reason for using this is that it's an enum compatible with aggressive minifiers. I don't think we're minifying in a way that requires this yet, but I don't think there's much risk to keeping this since it has no dependencies.

[hyperobject]

@rschamp The biggest quirk of Object.assign is the way it handles arguments. lodash.defaults({a: 'b', c: 'd'}, {a: 'e'}); returns {a: 'b', c: 'd'}, while Object.assign({a: 'b', c: 'd'}, {a: 'e'}); returns {a: 'e', c: 'd'}.

Additionally, lodash.defaults does not mutate objects passed into it, while Object.assign does mutate objects passed into it.

[mewtaylor]

@rschamp fwiw I am fine with keeping react-formsy at the moment. I can see what you mean about the input validating itself in the context of project/studio text areas, but I'd be more interested in at least exploring the idea of submitting an upstream PR before refactoring the whole thing with a new library (or based on our own implementation, which would take a lot of boilerplate). It kind of reminds me of the form class in Django the way it's currently set up, which is something we do use for single-input forms currently in a couple places.

[rschamp]

The only difference I see between Object.assign and lodash.defaults is the order the source object attributes are applied, but they can achieve the same thing. The way we use lodash.defaults, we expect arguments to be mutated, e.g. https://github.com/LLK/scratch-www/blob/99c76ee3bfd29e8ffb05cc7fc9a987019a7cef66/src/lib/api.js#L18-L23, so I think they're equivalent in that way.

I don't think you can use the mutating method of Object.assign in the same way as lodash.defaults, since the target values will always be overwritten by the source (rather than just treating them as defaults). E.g.,

var opts = {a: 1, b: 2, c:3};
defaults(opts, {a: 'a', b: 'b', c: 'c', d: 'd'});
// {a: 1, b: 2, c: 3, d: 'd'}
// opts = {a: 1, b: 2, c: 3, d: 'd'}

Object.assign(opts, {a: 'a', b: 'b', c: 'c', d: 'd'});
// {a: 'a', b: 'b', c: 'c', d: 'd'}
// opts = {a: 'a', b: 'b', c: 'c', d: 'd'}

Object.assign({a: 'a', b: 'b', c: 'c', d: 'd'}, opts);
// {a: 1, b: 2, c: 3, d: 'd'}
// opts = {a: 1, b: 2, c:3} (unchanged)

// Equivalent to lodash.defaults
opts = Object.assign({a: 'a', b: 'b', c: 'c', d: 'd'}, opts);
// {a: 1, b: 2, c: 3, d: 'd'}
// opts = {a: 1, b: 2, c: 3, d: 'd'}

But to me, this is actually a good thing about Object.assign, because functions that mutate arguments can lead to unexpected behavior.

I am for removing lodash.defaults in favor of Object.assign if we can achieve the same thing with both (in general, I'm for replacing any dependency with an equivalently convenient Javascript implementation if possible). Then whenever we use this functionality, we won't have to install a dependency in every codebase. This is with the understanding that lodash.defaults isn't going to change much, and doesn't matter too much as a dependency. Mostly just that if we can have consistent idioms in our code across codebases without using a dependency, then we should do that. Curious though what @thisandagain and @mewtaylor think of this.

I agree @mewtaylor I think we should keep react-formsy around until it causes us problems.

[rschamp]

We should also enable Greenkeeper.