The app itself is not ARM specific, but the base Docker image and its dependencies (Debian + libraries + nodejs binaries...) are platform specific, so they can't build that image on a different platform than their target.
See that, for the same tag (version) you have images with different hashes (hence content) for different architectures:
That makes no sense to me. It doesn’t matter what the base image is — the application and test suite are platform agnostic.
So, why not build two different Docker images that are the same except for arch? It seems that the problem isn’t the difference between dev and production environments, but the way Docker is being used. Sure, run an arch specific test before moving something to production, that makes sense. But for development, just use the Docker image that matches the dev arch. This seems like a much easier problem than the author is making it out to be.
Before Docker, I don’t think this would have been an issue.
It makes sense if you take in account that you're packaging the whole stack in a container. It's the same than when you make 'golden images' for a VM with Packer or whatever tool is available: you end up with a platform specific image.
But you aren't far fetched at all with that idea you have, and can be done using a Docker multi-stage build: You build all your application with whatever platform you have (either locally or for CI), and then you import your application layer from an ARM64 image in one side, and from and AMD64 in the other.
We aren't still very used to multi-platform development environments, so the tooling isn't still perfect (at all).
See that, for the same tag (version) you have images with different hashes (hence content) for different architectures:
https://hub.docker.com/_/node?tab=tags