devtools-frontend VS git-cache-tag

You can paste that curl command into https://curlconverter.com/wget/ to turn it into a Wget command.

> The reason there isn't a "Copy as wget" option, I think, is the level of control that curl allows so the request can be tailored to exactly mimic the browser.

This is not true. You can read the code that generates the curl command and it's pretty straightforward:

https://github.com/ChromeDevTools/devtools-frontend/blob/c9a...

The arguments it uses are --url, --data-raw, -X/--request, -H/--header, --compressed and --insecure, all of which Wget has an analog of. I think the reason is that they don't care to do it and/or they don't want to make that dropdown menu 30 entries long.

The GitHub mirror of the Chrome DevTools repo has the node_modules folder here: 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/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.

While you are correct about Google's monorepository, the author works on Chrome DevTools. That repository is open-source and standalone: https://github.com/ChromeDevTools/devtools-frontend

What's new in DevTools (Chrome 95).

2 known issues:

- DevTools doesn't display the viewport. I'm not sure if this is due to a change in the latest Chrome to which I just updated (~90) or because I broke my serving of it by updating it. A workaround will be serving a static snapshot of the devtools front-end rather than just (simply, as I'm doing right now) pulling it out of Chrome's RDP endpoint each time. This may take some time to do.

- DevTools doesn't seem to work on iOS (as I've tested it, Safari or Chrome).

- There are many more issues, and a lot, but not all, of them are edge cases but they'll be fixed eventually.

More bug reports, UI/UX tips and advice, and other feedback are very welcome! Unfortunately the whole app is not open source but some parts are open source, namely, the virtualized browser[0], and the devtools-front-end[1].

[0]: https://github.com/i5ik/ViewFinderJS

[1]: https://github.com/ChromeDevTools/devtools-frontend

Oh wow, this seems pretty similar to this thing I wrote: https://github.com/unqueued/git-cache-tag

Which saves all uncommitted changes to a tag.

I wrote it because I wanted to have a complete snapshot of a build context. Sometimes composer or npm can't be relied upon to reproduce dependencies in the state they used to be, or I just want a cache of artifacts. It has been pretty handy.

I think that having rapid access to node_modules can be very helpful sometimes. The solution I came up with was this:

https://github.com/unqueued/git-cache-tag

It copies all untracked stuff (including node_modules) into a leaf tag. It is fairly easy to manage them, or find the latest one. And because they are leaves, they can be pruned and completely garbage collected when they aren't useful anymore.

I have been burnt many times by npm, and I use this script to guarantee that I have a stash of my node_modules, while also keeping my project small.

And I have diffed different snapshot tags to see which module changed that broke something.

And by leaving everything in unaltered text, it exposes it to git which does a great job at compression stuff, especially highly differential revisions of my node_modules.

A 500M node_modules from one of my projects only weighed about 100M extra, even with several snapshots. And I can just delete them anyway.

I need to work on it a lot more, it was just a quick and dirty solution when I had to work with React Native a few years ago.