5 ms·

What’s worse is that the whole installing multiple versions of the same package for different sub dependencies doesn’t make any sense when when the language sup

What’s worse is that the whole installing multiple versions of the same package for different sub dependencies doesn’t make any sense when when the language supports singletons and module level variables with has no way of specifying which version to import. I was shocked this behavior exists when a site broke by upgrading a sub dependency. Turned out they both installed react so they used a different “creatContext” and now there were two context instances instead of one.

tristanstcyr 7y ago
React would normally be a peerDependency and so you shouldn't run into this problem if dependencies are specified properly. If not, NPM module flattening should take care of it. Then worst case, you can also tell webpack to bundle a specific installation. There are some ways to solve these problems...
- parhamn 7y ago
  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 7y ago
    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 7y ago
      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 7y ago
        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.

tristanstcyr 7y ago

React would normally be a peerDependency and so you shouldn't run into this problem if dependencies are specified properly. If not, NPM module flattening should take care of it. Then worst case, you can also tell webpack to bundle a specific installation. There are some ways to solve these problems...

parhamn 7y ago
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 7y ago
  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 7y ago
    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 7y ago
      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.