2026-04-05 Easter 2026
Christ has risen, rejoice! I have a bit of a rough time right now, but we have Good News – Jesus is greater than our troubles!
Like in previous years, rest assured that I will pray a decade of the Rosary for all of you, my dear readers.
Hallelujah!
2026-03-30 Node.js and .env files
The more I work with Node.js, the more I appreciate its built-in features. Supply chain attacks are a real thing and the more I can do without pulling in megabytes (or even kilobytes) of dependencies, the better.
For example, one of the very common patterns in Node applications are configs in .env files. The traditional way to digest them is to use dotenv, which admittedly has zero dependencies – but nowadays even that is not necessary. You can just run Node with --env-file .env, and the variables from .env will be loaded into process.env. (There is also --env-file-if-exists, which silently fails instead of throwing if the given file does not exist.) This works much like the dotenv package – if something is already in process.env, the value from the .env file is discarded, you can use comments (starting with #) in the .env file, etc. Even better, you can use --env-file more than one time, and a few .env files will be read in, with values in later files overriding values from the earlier ones. That way, you can have a general .env file and an .env.dev file with local overrides (although whether it’s a good practice is another question). You can also use this feature in a dotenv-like style where instead of a command-line option you call process.loadEnvFile at the beginning of your script. There is even util.parseEnv, which accepts a string and returns an object containing the key-value pairs resulting from its parsing.
One feature that sets this apart from dotenv is that you can use this to set variables that configure Node itself. For example, you can say
NODE_OPTIONS=--title=some-node-app
in .env, and when you run node --env-file .env your-app.js, ps
aux will show you some-node-app instead of node --env-file .env
your-app.js. As far as I know, this is something dotenv (which operates on a different level) cannot do.
This behavior has some quirks, though. Apparently parsing CLI arguments is not entirely consistent. I created this file:
console.log('process.argv:', process.argv)
console.log('NODE_OPTIONS:', process.env.NODE_OPTIONS)
console.log('SOME_OPTION:', process.env.SOME_OPTION)
setTimeout(() => {}, 10 * 1000)
and this .env fle:
SOME_OPTION=some option NODE_OPTIONS=--title=some-node-app
and said node --env-file .env test.js. Unsurprisingly, this is what I’ve got:
process.argv: [ '/usr/bin/node', '/.../test.js' ] NODE_OPTIONS: --title=some-node-app SOME_OPTION: some option
and $ pgrep -a node showed
1225363 some-node-app
So far, so good. But watch this:
$ node test.js --env-file .env process.argv: [ '/usr/bin/node', '/.../test.js', '--env-file', '.env' ] NODE_OPTIONS: undefined SOME_OPTION: undefined
So, Node treated –env-file .env as parameters to my script and not to Node itself (correctly) – but somehow still used it:
$ pgrep -a node 1226282 some-node-app
Why this happens I have no idea. I suspect it’s a weird (and hopefully harmless) bug in Node itself I plan to report.
Anyway, as you can see, you might not need dotenv anymore. In fact, thanks to this, my most recent project (which I will certainly blog about soon!) is a Node CLI tool with zero dependencies.
While at that, let me also mention another cool feature which landed in Node v25.0.0 (so it will be available in the next LTS version in a month or two). Prior to Node v25, you could console.log a regex and see this:
Since v25, the output has the regex colored:
How cool is that!?
2026-03-23 Disabling Eslint in one line with Tide
When coding in JavaScript, I use Eslint like everybody else. (Let’s set the discussion about Eslint vs. Oxlint for another time.) One problem I have is that sometimes (rarely, but not never) I need to tell Eslint that I broke one of the rules intentionally and I don’t want it to nag me about it. The easiest way is to put a comment saying
// eslint-disable-next-line <name of the rule I broke>
directly above the offending line. Trouble is, I never remember the exact syntax of that line (is it eslint-disable-next-line? or disable-eslint-next-line, or maybe eslint-disable-line…?), not to mention the name of the rule. (Yes, it appears in the echo area. No, you can’t easily copy it from there. Well, you can say C-u C-x =, press RET on the [Show] button next to the flycheck-error property name. Or you can just head to the *Messages* buffer after seeing the rule name in the echo area and copy it from there. Either way, it’s not exactly convenient.)
I figured that having a function to add such a comment automatically would be pretty cool. Of course, I would have to dive in Flycheck internals. As usual in such cases, I decided to start with checking if such a function exists already. Also as usual, I was not disappointed! I have Tide installed, and it turns out that it defines a command tide-add-eslint-disable-next-line which does exactly what I need! One caveat is that the Eslint checker must be enabled in Flycheck for this to work.
That’s it for today, come next week for another post!
CategoryEnglish, CategoryBlog, CategoryEmacs, CategoryJavaScript