4 ms·

Wow, that React Native dep graph is crazy! But as I browse it, most of the dependencies seem to be build-time, not runtime dependencies (i.e. it seems like mos

Wow, that React Native dep graph is crazy! But as I browse it, most of the dependencies seem to be build-time, not runtime dependencies (i.e. it seems like most of them are related to Babel). The React comparison doesn't include dev dependencies. While react-native does have more dependencies than vanilla react, on first glance the list doesn't seem too crazy https://github.com/facebook/react-native/blob/master/package.json#L87 https://github.com/facebook/react-native/blob/master/package...

filleduchaos 6y ago
The package.json file hasn't been remotely close to representative of the actual dependency count of a JS project for years.
- peterhunt 6y ago
  sure, but it gives you the list of packages to look at in the dependency visualizer
  - filleduchaos 6y ago
    It gives you a list of directly depended-upon packages. It doesn't give you a list of _those_ packages' dependencies, or _their_ dependencies, which funnily enough also get installed when you install your direct dependencies. Plus I forgot to address this in my earlier comment: that visualizer only shows dependencies. By default it doesn't load any dev dependencies. You can confirm that for yourself by checking out https://npm.anvaka.com/#/view/2d/rollup https://npm.anvaka.com/#/view/2d/rollup for example - only the single runtime dependency on fsevents shows up, the dozens of dev dependencies Rollup has don't. So yes, React Native does ship that overcomplicated graph of dependencies to all its users. I'll grant that at least _some_ of the code in those dependencies gets tree-shaken out.
    - andrewingram 6y ago
      Your last paragraph is a bit inaccurate. The dependencies are needed by people developing WITH React Native as opposed to devDependencies (which are for people developing ON React Native). So whilst you will be using the complicated graph of dependencies at some point, that isn't the same as saying they'll be shipped to end users of the app. The line between dependencies and devDependencies got blurry the second npm packages got used for more than just Node.js itself. What's really needed to remove the ambiguity is something like prodDependencies, which would be a subset of the current dependencies, but I don't know if it's really worth it.
      - haskman 6y ago
        Can you clarify the difference between developing "with" vs "on" react-native?
        ZiiS 6y ago
        If you are trying to write an app using react-native, or if you are trying to improve react-native.
bigiain 6y ago
Am I the only one who just spent 5 minutes chasing moving nodes round in that graph looking for leftpad.js?
- searchableguy 6y ago
  Definitely not.
- captivechains 6y ago
  it's in there, somewhere.. https://github.com/microsoft/react-native-windows/blob/master/yarn.lock#L8737 https://github.com/microsoft/react-native-windows/blob/maste...
- ci5er 6y ago
  Why don't people copy the deb-tree to their local repo and/or pin the version that they want, so that they can be free of node terrorists? EDIT: To be clear - maybe I am REALLY old-school, but every time we did a release, we archived our tool-chain (GCC blah blah, Make blah blah, bash blah blah), our depencies, our vendor libraries and our code, so that IF in 20 years, if we had to rebuild a particular release (12.x) for a particular client (Chase) on a particular platform (AIX), we could do so de novo. Maybe that was overkill, but in a world where everything changes, why wouldn't you snapshot everything for every release?
  - mlvljr 6y ago
    "if your a dad, yes, doh!"
  - nicoburns 6y ago
    This makes sense if you're releasing versioned software builds to 3rd parties. If you're running it internally (e.g. as a SaaS company) then there's much less cause to run an old versions, let alone one from 20 years ago.
    - ci5er 6y ago
      Yeah. I get that. Getting enterprise people to migrate or go off-prem for everything takes some time. And some like custom versons! I just like to snap-shot everything (including the tool chain) so that I can recreate the past out of my repository at any time for any reason. (I'm weird like that - I expect the same out of legal, ops and accounting as well) Maybe I'm old - but I don't trust Quickbooks-in-the-Cloud. EDIT: But I use 'em!
tomphoolery 6y ago
The longer you leave that dependency graph up, the more it starts to look like the Huddle from Inside...
deleted 6y ago
[deleted]

filleduchaos 6y ago

The package.json file hasn't been remotely close to representative of the actual dependency count of a JS project for years.

peterhunt 6y ago
sure, but it gives you the list of packages to look at in the dependency visualizer
- filleduchaos 6y ago
  It gives you a list of directly depended-upon packages. It doesn't give you a list of _those_ packages' dependencies, or _their_ dependencies, which funnily enough also get installed when you install your direct dependencies. Plus I forgot to address this in my earlier comment: that visualizer only shows dependencies. By default it doesn't load any dev dependencies. You can confirm that for yourself by checking out https://npm.anvaka.com/#/view/2d/rollup https://npm.anvaka.com/#/view/2d/rollup for example - only the single runtime dependency on fsevents shows up, the dozens of dev dependencies Rollup has don't. So yes, React Native does ship that overcomplicated graph of dependencies to all its users. I'll grant that at least _some_ of the code in those dependencies gets tree-shaken out.
  - andrewingram 6y ago
    Your last paragraph is a bit inaccurate. The dependencies are needed by people developing WITH React Native as opposed to devDependencies (which are for people developing ON React Native). So whilst you will be using the complicated graph of dependencies at some point, that isn't the same as saying they'll be shipped to end users of the app. The line between dependencies and devDependencies got blurry the second npm packages got used for more than just Node.js itself. What's really needed to remove the ambiguity is something like prodDependencies, which would be a subset of the current dependencies, but I don't know if it's really worth it.
    - haskman 6y ago
      Can you clarify the difference between developing "with" vs "on" react-native?
      - ZiiS 6y ago
        If you are trying to write an app using react-native, or if you are trying to improve react-native.

bigiain 6y ago

Am I the only one who just spent 5 minutes chasing moving nodes round in that graph looking for leftpad.js?

searchableguy 6y ago
Definitely not.
captivechains 6y ago
it's in there, somewhere.. https://github.com/microsoft/react-native-windows/blob/master/yarn.lock#L8737 https://github.com/microsoft/react-native-windows/blob/maste...
ci5er 6y ago
Why don't people copy the deb-tree to their local repo and/or pin the version that they want, so that they can be free of node terrorists? EDIT: To be clear - maybe I am REALLY old-school, but every time we did a release, we archived our tool-chain (GCC blah blah, Make blah blah, bash blah blah), our depencies, our vendor libraries and our code, so that IF in 20 years, if we had to rebuild a particular release (12.x) for a particular client (Chase) on a particular platform (AIX), we could do so de novo. Maybe that was overkill, but in a world where everything changes, why wouldn't you snapshot everything for every release?
- mlvljr 6y ago
  "if your a dad, yes, doh!"
- nicoburns 6y ago
  This makes sense if you're releasing versioned software builds to 3rd parties. If you're running it internally (e.g. as a SaaS company) then there's much less cause to run an old versions, let alone one from 20 years ago.
  - ci5er 6y ago
    Yeah. I get that. Getting enterprise people to migrate or go off-prem for everything takes some time. And some like custom versons! I just like to snap-shot everything (including the tool chain) so that I can recreate the past out of my repository at any time for any reason. (I'm weird like that - I expect the same out of legal, ops and accounting as well) Maybe I'm old - but I don't trust Quickbooks-in-the-Cloud. EDIT: But I use 'em!

tomphoolery 6y ago

The longer you leave that dependency graph up, the more it starts to look like the Huddle from Inside...

deleted 6y ago

[deleted]