WTF

/Users/me/my_company/my_project/node_modules/gulp-sass/node_modules/node-sass/node_modules/pangyp/bin/node-gyp

this is getting ridiculous

Best: Notepad++. I don't use it to code, but it's so versatile.
Worst: node-gyp.

So I have to install visual studio which will take about 8gb of space for node-gyp to work.

WHY THE FUCK DID I SWITCH? I WAS HAPPY WITH MY LINUX

NOOOOOOOOOOOOOO

I hate Sass.

When installing all NPM dependencies with npm i, it's always quick, but not with sass. Ooooh myy goood. It starts compiling. It always misses something. Your node version is always not what sass needs. It pulls out gyp which requires some native shit. The build is never reproducible, it always fails with some horrible two mile long poorly-formatted stacktrace that is just gibberish.

More than that, sass is just poorly designed tool used by frontend fuckboys to write imperative, nonstandard, non-maintainable styles. If you know shit about css, you don't need sass.

I'm so happy it's going to die along with gulp. Webpack and css modules are here.

Yes, css-in-js that has a runtime penalty is also shit. If you like its syntax but dislike everything else, use Linaria. It has no runtime penalty and looks just like other css-in-js solutions.

Lesson learned: Always use node LTS in production, library maintainers are lazy af.

Building a new machine for NodeJS. Installing Gulp-sass has a dependency on node-sass - which has a dependency on node-gyp - which has a dependency ON PYTHON!!!

and.... python 2.7, as it doesn't support 3.0

Doomed - We're all doomed.

Lessions I learned so far from my first big node/npm project with tons of users:
1) If you didn't build something for a while, expect 3 hours of resolving version conflicts for every two weeks since the last build.
2) Even if the tests pass, run the containers on your own machine and make sure that the app doesn't randomly crash before deploying
3) Even if the app seemed to work on your own machine, run the tests again in an environment mimicking prod at most 15 minutes before replacing the running containers.
4) Even if all else indicates that the app will work, only ever deploy if you expect to be available within the 4 hours following a deployment.
5) Don't use shrinkwrap for anything other than locking every version down completely. A partial shrinkwrap will produce bugs that are dependent on the exact hour you built the app _and_ the shrinkwrap file, and therefore no one will ever have seen them other than you.
6) Avoid gyp, and generally try not to interface too much with anything that doesn't run on node. If parts of your solution use very different toolchains, your problems will be approximately proportional to the amount of code. And you'd be surprised just how much code you're running. (otherwise it's more logarithmic because the more code the less likely a new assumption is unique)
7) Do not update webpack or its plugins or anything they might call unless you absolutely need to
8) Containers are cool but the alpine ones are pretty much useless if you have even just one gyp module.
9) There's always another cache. To save yourself a lot of pain, include the build time in every file or its name that the browser can download, and compare these to a fresh build while debugging to assert that the bug is still present in the code you're reading
+1) Although it may look like it, SQLite is far from a simple solution because the code and the bindings aren't maintained. In fact, it'll probably be more time consuming than using a proper database.

wtf is up with node-sass? Basically every project I've ever worked on breaks because it can't build with node-gyp anymore or whatever

By gods, being forced to install node-gyp on windows feels like a very cruel version of hell. Why we haven't yet migrated from node-sass is beyond me.

Quick disclaimer, it is easily googlable, but no matter where I search, I can't find a solution. This is why I'm trying here.

Okay, so the other day, I was trying to install the node package sqlite3, and it spat out errors all day long from the node-pre-gyp native module and from the node-gyp native module. I am using the latest LTS (as of 5/10/2018), and I can't get any answers on HOW TO FIX IT...! Please HALP ASAP!

You know you are screwed when you get a webpack error like "Module build failed" Babel cannot find module @babel-plugin-some-nonesense" & gyp module build failed because of fucked C++ node versions, go find the right node for you & you better start the project webpack config and .babelrc from scratch because you ain't getting anywhere with these errors.

Laravel use SASS,
SASS installed through NPM & compiled with Node-gyp,
Node-gyp need build tools each platform,
Build tools for Windows is Visual Studio.
So, I need to install Visual Studio to compile SASS?

GREAT!!!

I decided to use Docker Compose on a tiny project that essentially consists of an API and a Caddy server that serves static files and proxies to the API, all of this running on an EC2 t1-nano. I made this admittedly odd choice because I wanted to learn Compose and simultaneously forego figuring out why the node-gyp bindings for sqlite3 refuse to build on EC2 even though it builds just fine on my machine.

I am storing secrets in .env which is committed into the private GH repo. Just now I came across a rant that described the same security practice and it sounded pretty bad from an outside perspective so I decided to research alternatives.

Apparently professional methods for storing secrets generally have higher system requirements than a t1-nano. I'm not looking for a complex service orchestration system, I'm not trying to run an enterprise on this poor little cloud-based raspberry pi. I just want to move my secrets out of the Git repo,

Any tips?

trying to make node-gyp work on Windows so that a single dependency out of a dozen would work