4 ms·

1. Randomly peeking at process.argv and process.env all around. Other weird layering violations, too. 2. Tons of repeat code, eg. multiple ad-hoc implementati

by q3k 7mo ago

1. Randomly peeking at process.argv and process.env all around. Other weird layering violations, too. 2. Tons of repeat code, eg. multiple ad-hoc implementations of hash functions / PRNGs. 3. Almost no high-level comments about structure - I assume all that lives in some CLAUDE.md instead.

loevborg 7mo ago
You're right about process.argv - wow, that looks like a maintenance and testability nightmare.
- darkstar_16 7mo ago
  They use claude code to code it. Makes sense
s3p 7mo ago
It probably exists only in CLAUDE or AGENTS.md since no humans are working on the code!
delamon 7mo ago
What is wrong with peeking at process.env? It is a global map, after all. I assume, of course, that they don't mutate it.
- hu3 7mo ago
  For one it's harder to unit test.
- q3k 7mo ago
  It's implicit state that's also untyped - it's just a String -> String map without any canonical single source of truth about what environment variables are consulted, when, why and in what form. Such state should be strongly typed, have a canonical source of truth (which can then be also reused to document environment variables that the code supports, and eg. allow reading the same options from configs, flags, etc) and then explicitly passed to the functions that need it, eg. as function arguments or members of an associated instance. This makes it easier to reason about the code (the caller will know that some module changes its functionality based on some state variable). It also makes it easier to test (both from the mechanical point of view of having to set environment variables which is gnarly, and from the point of view of once again knowing that the code changes its behaviour based on some state/option and both cases should probably be tested).
- lioeters 7mo ago
  > process.env? It is a global map That's exactly why, access to global mutable state should be limited to as small a surface area as possible, so 99% of code can be locally deterministic and side-effect free, only using values that are passed into it. That makes testing easier too.
- withinboredom 7mo ago
  environment variables can change while the process is running and are not memory safe (though I suspect node tries to wrap it with a lock). Meaning if you check a variable at point A, enter a branch and check it again at point B ... it's not guaranteed that they will be the same value. This can cause you to enter "impossible conditions".
  - efskap 7mo ago
    Wait, is it expected for them to be able to change? According to this SO answer [0] it's only really possible through GDB or "nasty hacks" as there's no API for it. [0] https://unix.stackexchange.com/questions/38205/change-environment-of-a-running-process https://unix.stackexchange.com/questions/38205/change-enviro...
    - withinboredom 7mo ago
      The process itself (including other threads) can call setenv whenever it wants.

by q3k 7mo ago

loevborg 7mo ago

You're right about process.argv - wow, that looks like a maintenance and testability nightmare.

darkstar_16 7mo ago
They use claude code to code it. Makes sense

s3p 7mo ago

It probably exists only in CLAUDE or AGENTS.md since no humans are working on the code!

delamon 7mo ago

What is wrong with peeking at process.env? It is a global map, after all. I assume, of course, that they don't mutate it.

hu3 7mo ago
For one it's harder to unit test.
q3k 7mo ago
It's implicit state that's also untyped - it's just a String -> String map without any canonical single source of truth about what environment variables are consulted, when, why and in what form. Such state should be strongly typed, have a canonical source of truth (which can then be also reused to document environment variables that the code supports, and eg. allow reading the same options from configs, flags, etc) and then explicitly passed to the functions that need it, eg. as function arguments or members of an associated instance. This makes it easier to reason about the code (the caller will know that some module changes its functionality based on some state variable). It also makes it easier to test (both from the mechanical point of view of having to set environment variables which is gnarly, and from the point of view of once again knowing that the code changes its behaviour based on some state/option and both cases should probably be tested).
lioeters 7mo ago
> process.env? It is a global map That's exactly why, access to global mutable state should be limited to as small a surface area as possible, so 99% of code can be locally deterministic and side-effect free, only using values that are passed into it. That makes testing easier too.
withinboredom 7mo ago
environment variables can change while the process is running and are not memory safe (though I suspect node tries to wrap it with a lock). Meaning if you check a variable at point A, enter a branch and check it again at point B ... it's not guaranteed that they will be the same value. This can cause you to enter "impossible conditions".
- efskap 7mo ago
  Wait, is it expected for them to be able to change? According to this SO answer [0] it's only really possible through GDB or "nasty hacks" as there's no API for it. [0] https://unix.stackexchange.com/questions/38205/change-environment-of-a-running-process https://unix.stackexchange.com/questions/38205/change-enviro...
  - withinboredom 7mo ago
    The process itself (including other threads) can call setenv whenever it wants.