Production reported that the web framework was not being monitored, even though the monitoring setup was the first thing in the entry file.
Why the first line was not first
Monitoring libraries work by patching a framework as it loads. For that to work, they have to be set up before the framework is imported.
In an ES module, import statements are resolved before any other line in the file runs, wherever they appear. So a call written above the imports still executes after them. The framework had already loaded, unpatched, by the time the monitoring setup ran.
The file read top to bottom in one order and executed in another.
The repair
I moved the setup into its own small module and had the runtime load that module before the application starts, using Node's option for preloading a module. Because it is an option on the process and not a line in a file, it cannot be reordered by accident.
It had to be applied everywhere the service is started: the development command, the production command and the container. Missing one would have produced a service that is monitored in one environment and blind in another.
A side effect worth knowing
A logging helper that runs in a worker thread inherited the same startup option and tried to load the monitoring module too. I had to stop the option being passed down to it. Preloading affects everything the process starts, which is easy to forget.
The general rule
Startup has an order, and some things have to be at the front of it: monitoring, configuration checks and anything else that needs to see the application being built. Where that order matters, I put it somewhere the language cannot rearrange.