[parhamn]

Sure (upvote) and we dealt with it accordingly after some confused digging. On a more general level I’ve never seen something like that in a package manager. It seems as though some of the language features (like the singleton I mentioned) would make it obvious that arbitrarily duplicating packages and scoping them to sub packages is a major no-no, as in most languages I’ve dealt with.

[jessaustin]

It seems like a weird thing about React, or maybe how you're using it, that this is a problem. Most packages, and the language itself, handle multiple simultaneous versions of dependencies without issue. If packages are doing the old-fashioned "stick a property on window" thing instead of just getting required or imported browserify-style, they can step on each others' toes (and it's totally possible that React is dumb enough to step on its own toes). It has been years since that was necessary. browserify or more recent tools like parcel or webpack should be used instead.

[parhamn]

That’s not really relevant, right? No mater the loading/transpiration step, you lose a lot of language guarantees when you can load multiple of the same packages, including:

- function/object identity checking I.e “package.func !== package.func” in many cases places.

- module level singletons and registry (e.g createContext useContext)

- single initialization

- others I can’t think of

That’s not typical and I was surprised by it.

[jessaustin]

Loading multiple versions of the same package is just something that you can do in javascript. As complained about many other times ITT, any big node tool does this as a matter of course. Over on the browser, react isn't my favorite, but I'll admit that all that complexity serves some purpose. Maybe it would be nice if it were just a bit more complex so that global contexts could be backwards-compatible, but I guess it's not. Still, if you hire developers, they should be able to handle this sort of thing.