Investigate dropping all external dependencies

We currently have two external dependencies: https://github.com/zertosh/loose-envify and https://github.com/benlesh/symbol-observable .

loose-envify appears to be used in package.json, but only as some kind of polyfill / build plugin for Browserify:

https://github.com/reduxjs/redux/blob/85024d431ca765c843561be6792edeb7890d5fce/package.json#L102-L106

symbol-observable is used in createStore as a polyfill for Symbol.observable, to allow compatibility for treating the Redux store as an observable:

https://github.com/reduxjs/redux/blob/85024d431ca765c843561be6792edeb7890d5fce/src/createStore.ts#L1

https://github.com/reduxjs/redux/blob/85024d431ca765c843561be6792edeb7890d5fce/src/createStore.ts#L331-L333

I would like to strongly consider dropping both of those dependencies if at all possible.

I question whether we need to have any specific support for Browserify in here. If there’s a build step that needs to be done, let the end users take care of it. No reason to have an installation dep just for that.

symbol-observable boils down to this 15-line file for the polyfill plus another 15 lines for figuring out what the global object is.

@davidkpiano suggests rolling our own symbol-observable if really needed.

Finally, we are currently talking about adding ts-toolbelt as a dependency for its compose function. I would like us to seriously investigate whatever other alternatives are out there to adding a dep, even if it’s one that ultimately compiles away.

[markerikson]

I have commented several times that the JS ecosystem would be well served by trying to do some consolidation and reduce tiny dependencies. There’s no reason that a CRA+TS app should end up with 1500 deps downloaded.

In Redux’s case specifically, there’s no need to add a package dependency just to get this tiny polyfill. I would love to see v5.0 have zero additional dependencies after installation.

[Andarist]

I agree that this was a strange issue on our side, and not something that happens daily - but a centralized package for those React types would actually save hours of debugging in this case. So it’s not really that “not much can be done to fix that”. I understand though that this is an edge case and not a strong argument in favor of this - just something I’ve wanted to mention.

As to the byte overhead - it’s 90 bytes difference (minified+gzipped on both). So not really something I would personally call a significant gain.

Don’t get me wrong - I’m here just to discuss as I’m interested in general reasoning/arguments behind changes like this. Lately, I’ve noticed people wanting to get rid of all dependencies and I just wonder why that is. Personally I don’t like bloated dependencies myself either, but inlining really small helpers just for sake of removing a dep is somewhat against composition for me.