4 ms·

The GitHub mirror of the Chrome DevTools repo has the node_modules folder here: https://github.com/ChromeDevTools/devtools-frontend/blob/main/node_modules/ http

The GitHub mirror of the Chrome DevTools repo has the node_modules folder here: https://github.com/ChromeDevTools/devtools-frontend/blob/main/node_modules/ https://github.com/ChromeDevTools/devtools-frontend/blob/mai... But there is nuance (there always is...), the README file in node_modules is here: https://github.com/ChromeDevTools/devtools-frontend/blob/main/node_modules/README.chromium https://github.com/ChromeDevTools/devtools-frontend/blob/mai... - and it makes it clear the only NPM dependencies used by the build-system or infrastructure is meant to be checked-in. Other NPM packages should not. ---------- In conclusion: the linked blog-article is clickbait that misrepresents how the Chrome team manages their dependencies.

malkia 5y ago
Maybe I'm wrong, but I see quite a lot of node_modules here - https://source.chromium.org/chromium/chromium/src/+/main:third_party/devtools-frontend/src/node_modules/ https://source.chromium.org/chromium/chromium/src/+/main:thi... Here are all "node_modules" folders I can find (sorry I'm not much familiar with npm/js to know more) https://source.chromium.org/search?q=file:node_modules%2F$%20pcre:yes https://source.chromium.org/search?q=file:node_modules%2F$%2...
- malkia 5y ago
  This file seems to be controlling what gets ("checked-in") - https://source.chromium.org/chromium/chromium/src/+/main:third_party/devtools-frontend/src/scripts/deps/manage_node_deps.py;bpv=1 https://source.chromium.org/chromium/chromium/src/+/main:thi... In our industry (games) we often do that - checkin prebuilt code in the depots (typically "p4"). I'm not saying it's wrong/right, it's just what we do (not 100% fully, but almost, though people in IT/infra tend to do otherwise).
  - DaiPlusPlus 5y ago
    Ah Perforce... you have my sympathy. Does your team/company store art and asset blobs (even rendered FMVs?) in Perforce too, or do you have a separate asset-management system for that? If you do have two separate systems, how do you keep the asset-store and source-control in-sync? It's been a long time (easily 20 years now) since I dabbled in any high-end creative software (like 3ds, etc), but I remember they generally all had large binary singleton project files (like Flash .fla and Photoshop .psd files) that couldn't be deconstructed and effectively diffed by any source-control system (though Flash eventually supported external ActionScript source-files), I'm curious how that affects your org's asset storage needs.
    - dijit 5y ago
      The main reason to use perforce in the first place is because of assets. Locking of files too, but that’s only necessary on non-diffable assets.
      - DaiPlusPlus 5y ago
        I've only ever used Perforce through a command-line interface. What's the UX like when using Perforce for blobs/assets? Does everyone have to use the command-line or is there a GUI experience (with fast-rendering thumbnails?)? Forgive the questions, I'm just curious about the minutia and peculiarities of the gaming-biz because I've never worked in the field.
        davedx 5y ago
        I used Perforce 10-15 years ago, it had a pretty solid GUI application. I never used the CLI.
        dijit 5y ago
        The CLI is punishing as hell. Most game engines natively integrate with perforce so it's largely invisible. Those that don't use the engine typically use an IDE which automatically checks out files; then they just check them in using the p4 GUI. Even I don't use the commandline and I'm a CLI-Junkie.
    - malkia 5y ago
      We ... commit them. Probably some really exceptional cases stay behind some "ftp"-like service (not really ftp, something like this). It maybe wasteful, but it's the established practice (it seems). People coming from other game companies pretty much use it too (some rare exceptions). Also the automotive/chip design industry uses them - and yes mainly for the big blobby non-diffable/mergeable assets. Locks are terrible, and yet you gotta doit sometimes, as how else would you prevent people working on the same asset. I'm (still) terrible with git, often screw up commits, and have to google search/stack overflow to get it right (I use it mainly for simple home projects). I can only imagine the pain and suffering a non-tech person would have with git. Also the metadata is quite lot for WFH conditions. Working remotely does not always mean working from a dumb terminal (I wish).

malkia 5y ago

Maybe I'm wrong, but I see quite a lot of node_modules here - https://source.chromium.org/chromium/chromium/src/+/main:third_party/devtools-frontend/src/node_modules/ https://source.chromium.org/chromium/chromium/src/+/main:thi... Here are all "node_modules" folders I can find (sorry I'm not much familiar with npm/js to know more) https://source.chromium.org/search?q=file:node_modules%2F$%20pcre:yes https://source.chromium.org/search?q=file:node_modules%2F$%2...

malkia 5y ago
This file seems to be controlling what gets ("checked-in") - https://source.chromium.org/chromium/chromium/src/+/main:third_party/devtools-frontend/src/scripts/deps/manage_node_deps.py;bpv=1 https://source.chromium.org/chromium/chromium/src/+/main:thi... In our industry (games) we often do that - checkin prebuilt code in the depots (typically "p4"). I'm not saying it's wrong/right, it's just what we do (not 100% fully, but almost, though people in IT/infra tend to do otherwise).
- DaiPlusPlus 5y ago
  Ah Perforce... you have my sympathy. Does your team/company store art and asset blobs (even rendered FMVs?) in Perforce too, or do you have a separate asset-management system for that? If you do have two separate systems, how do you keep the asset-store and source-control in-sync? It's been a long time (easily 20 years now) since I dabbled in any high-end creative software (like 3ds, etc), but I remember they generally all had large binary singleton project files (like Flash .fla and Photoshop .psd files) that couldn't be deconstructed and effectively diffed by any source-control system (though Flash eventually supported external ActionScript source-files), I'm curious how that affects your org's asset storage needs.
  - dijit 5y ago
    The main reason to use perforce in the first place is because of assets. Locking of files too, but that’s only necessary on non-diffable assets.
    - DaiPlusPlus 5y ago
      I've only ever used Perforce through a command-line interface. What's the UX like when using Perforce for blobs/assets? Does everyone have to use the command-line or is there a GUI experience (with fast-rendering thumbnails?)? Forgive the questions, I'm just curious about the minutia and peculiarities of the gaming-biz because I've never worked in the field.
      - davedx 5y ago
        I used Perforce 10-15 years ago, it had a pretty solid GUI application. I never used the CLI.
      - dijit 5y ago
        The CLI is punishing as hell. Most game engines natively integrate with perforce so it's largely invisible. Those that don't use the engine typically use an IDE which automatically checks out files; then they just check them in using the p4 GUI. Even I don't use the commandline and I'm a CLI-Junkie.
  - malkia 5y ago
    We ... commit them. Probably some really exceptional cases stay behind some "ftp"-like service (not really ftp, something like this). It maybe wasteful, but it's the established practice (it seems). People coming from other game companies pretty much use it too (some rare exceptions). Also the automotive/chip design industry uses them - and yes mainly for the big blobby non-diffable/mergeable assets. Locks are terrible, and yet you gotta doit sometimes, as how else would you prevent people working on the same asset. I'm (still) terrible with git, often screw up commits, and have to google search/stack overflow to get it right (I use it mainly for simple home projects). I can only imagine the pain and suffering a non-tech person would have with git. Also the metadata is quite lot for WFH conditions. Working remotely does not always mean working from a dumb terminal (I wish).