Oh, it's all unclass - thus why I would be discussing it in an open forum. 🙂 Interestingly, our biggest resistance to change is inside our own team. Our contract owner has asked us to investigate and switch to an Agile process (didn't specify which one - heh), but our CM folks are terribly hung up on "CMMI Level 3!" and "mature processes!". We managed to do a proof-of-concept on a project last year, and we were rolling until it came time to actually get the code to the field; then, it was "Oh no - that was just for development; we aren't changing anything in the process after that." The users said it was good just before Labor Day; it hit the field just before Thanksgiving. .sigh. This move that may end up with us commercial-first may also force them to adapt some of that - at least that's my hope.

You can talk about the work you do even in s or TS, unless you can't. Usually it's about the data, but yeah whole deploys can be tagged. Sometimes it's just which network is on like sipr

Over classification is a bane

Is it reasonable to assume the DOD has audited vscode? That'd be a nice service. How do they handle the possibility of a supply chain attack in the extension ecosystem?

There is a process, can't talk about beyond you run all requests to proxies that deal with it

related thought: i wonder if we've reached the point that dependencies should be checked in

this is how we used to do it: check in a bunch of jars

then maven came along and that was a bad idea

now I wonder if tools that do the transitive closure management against a persisted

/lib

folder is the right thing

it would also surface just how insane your dependency graph is, if you had to check in 80MB worth of

/lib

certainly for htmx, I wonder if we should check in the testing libraries since that's what requires npm for doing local dev

the tests are all run in-browser right?

yes

six total files needed

we copy them out to make the stuff off https://htmx.org/test work

that's our only dev-time dependency on npm

unfortunately I also picked 11ty for the static site generator, which brings in the usual js dependency insanity

but @gorgeous-ghost-95789 is going to switch us to a go-based ssg, so all good there, right @gorgeous-ghost-95789 ?

last time i installed go it created a non-hidden directory in my home :[

i'm always a little shocked how hard browser testing has proven using javascript testing tools

I vote we build our site using R

#1069737521522683934 rise up

https://gohugo.io/ this was the last go ssg I looked at, not bad, but a project

#929014829212123156 explain yourself

the good news is that the content in

/www

is pretty generic and could easily be ported to pretty much any ssg

a low-deps python-based ssg might be the rhymeyest option

Dunno if we're really winning much moving away from package-lock.json.. the packages locked in are already checked against an integrity hash, unless i'm missing something.

The devil could be in the details.. aka the hash could be created after downloading something, lol. Typical cheeky npm.