We’d need a lot more information on how, and which versions, were installed of pretty much the whole stack.
There are still no freely-available Silicon CI resources, so everything is for the most part only built under emulation/cross-compilation, and can’t really be tested very accurately. This approach could be taken for this case, as well, emulating a whole intel computer on this computer, with all the downsides that come with it. A virtualized/containerized solution might also work.
That being said, a great deal of the stack has been successfully used (and thereby anecdotally tested) by the community using a miniforge baseline for all relevant pieces (python, nodejs, etc), as indeed, a number of upstream binary packages still aren’t distributed for this relatively new, and very proprietary architecture, and might not be, automatically, if older/historical versions of binary dependencies are required.
If the kernel referred to is not on conda-forge, this could be requested or PRed on staged-recipes .
If this route doesn’t work, or sounds like too much work, there likely isn’t much that the Jupyter maintainers can do to help.
I’m looking for an alternative. I can run Nodejs and my code independently in a terminal. I just have to copy the code or snippets out to a .js file, but as far as Jupyter Lab goes, it looks like I’ve lost that capability until GNU C develops a glibc for the MAC M1s or I can figure a way to install glibc under Rosetta. I’m basically informing ya’ll this one limitation so maybe you developers will get together and fix it. I’ve sent GNU C and email, but I’m not a C or C++ programmer so I’m clueless on submitting a “new port” request.