// Note how '"GET" | "POST" | string' gets reduced to just "string" since it's the
// broadest type of the intersection? That's expected behaviour.

type HTTPMethod = "GET" | "POST" | string
//   ^?
//                        ^ This should be "string"

function doHTTP(method: HTTPMethod): void {
    console.log(method)
    //          ^?
    //             ^ This should be "(parameter) method: string".
}

doHTTP("")
//     ^ Press CTRL+SPACE here to try and get autocomplete. You should get nothing.

From the compiler's point of view, this is just a very fancy way of writing string. By the time we're looking for suggestions at [HTTPMethod], all the literals are lost.

— microsoft/TypeScript#29729

The trick is to fool the type checker into thinking that the | string part of the union type is magically (somehow?) different than the type of the literals -- that way it doesn't get reduced to just type T = string. The magic is string & {}.

// It works!

type HTTPMethod = "GET" | "POST" | (string & {})
//   ^?
//                        ^ This should be '(string & {}) | "GET" | "POST"'

function doHTTP(method: HTTPMethod): void {
   console.log(method)
   //          ^?
   //             ^ This should be "(parameter) method: HTTPMethod".
}

doHTTP("")
//     ^ Press CTRL+SPACE here to try and get autocomplete. You should get string literals!

// ...but you can also just type any string you want. This is valid.
doHTTP("not-an-http-method")

The type-fest npm package has a type for this exact use-case: LiteralUnion.

import type {LiteralUnion} from 'type-fest';

// Before

type Pet = 'dog' | 'cat' | string;

const petWithoutAutocomplete: Pet = '';
// Start typing in your TypeScript-enabled IDE.
// You **will not** get auto-completion for `dog` and `cat` literals.

// After

type Pet2 = LiteralUnion<'dog' | 'cat', string>;

const petWithAutoComplete: Pet2 = '';
// You **will** get auto-completion for `dog` and `cat` literals.

There was a TypeScript GitHub issue opened about having this "one" | "two" | string literal stuff work out of the box, but it didn't go anywhere. Microsoft/TypeScript#29729

TL;DR:

• node:process platform & node:os platform(): "netbsd", "os390", "win32", "darwin", "sunos", "freebsd", "openbsd", "linux", "android", "aix", "os400", "ios", "openharmony", "emscripten", "wasm", "wasi", "cloudabi"
• node:process arch & node:os arch(): "s390x", "arm64", "arm", "ia32", "mipsel", "mips", "mips64el", "ppc64", "x64", "riscv64", "riscv32", "loong64"
• node:os machine(): x86_64, ia64, i386, i486, i586, i686, mips, alpha, powerpc, sh, arm, unknown on Windows; ppc64 or any uname -m value on Unix.

node:process platform & node:os platform()

The Node.js process object is defined across some C++ files as a global object. The node:process module just reexports it with all the appropriate named properties. This means there's nothing to see in lib/process.js

'use strict';

// Re-export process as a built-in module
module.exports = process;

Instead, we have to jump to the src/node_*.cc files to see anything that defines process.* properties & methods. Don't worry about where and how this v8 process object gets set as a global variable; that's not important right now.

// process.platform
READONLY_STRING_PROPERTY(process, "platform", per_process::metadata.platform);

What's this per_process::metadata struct? Where is it defined? It must be some kind of singleton/constant since it's being used to access .platform as a property. Sure enough, it is!

// Per-process global
namespace per_process {
extern Metadata metadata;
}

namespace per_process {
Metadata metadata;
}

node::Metadata is a class that has a single constructor that sets .arch and .platform (std::string-s) to some #define-ed macro string literals.

class Metadata {
 public:
  Metadata();
  Metadata(Metadata&) = delete;
  Metadata(Metadata&&) = delete;
  Metadata operator=(Metadata&) = delete;
  Metadata operator=(Metadata&&) = delete;

  struct Versions {
    // -- ✂️ SNIP --
  }

  Versions versions;
  const Release release;
  const std::string arch;
  const std::string platform;
};

Metadata::Metadata() : arch(NODE_ARCH), platform(NODE_PLATFORM) {}

So far we know that node.platform is set to whatever value NODE_PLATFORM is set to. Where is that set? It's set by the GYP build system configuration.

{
  'target_name': '<(node_core_target_name)',
  'type': 'executable',

  'defines': [
    'NODE_ARCH="<(target_arch)"',
    'NODE_PLATFORM="<(OS)"', # 👈
    'NODE_WANT_INTERNALS=1',
  ],

  # -- ✂️ SNIP --
}

What's this OS variable? Where does it come from? It is a GYP predefined variable. I don't really know if you're supposed to manually set it or if it's inferred from your host platform.

• OS: The name of the operating system that the generator produces output for. Common values for values for OS are:

  • 'linux'
  • 'mac'
  • 'win'

  But other values may be encountered and this list should not be considered exhaustive.

— GYP input format reference docs

There are other files that appear to overwrite the value of NODE_PLATFORM to other values that are more specialized than just <(OS).

[ 'OS=="win"', {
  'defines!': [
    'NODE_PLATFORM="win"',
  ],
  'defines': [
    'FD_SETSIZE=1024',
    # we need to use node's preferred "win32" rather than gyp's preferred "win"
    'NODE_PLATFORM="win32"', # 👈
    '_UNICODE=1',
  ],
  # -- ✂️ SNIP --
]

[ 'OS=="mac"', {
  # linking Corefoundation is needed since certain macOS debugging tools
  # like Instruments require it for some features. Security is needed for
  # --use-system-ca.
  'libraries': [ '-framework CoreFoundation -framework Security' ],
  'defines!': [
    'NODE_PLATFORM="mac"',
  ],
  'defines': [
    # we need to use node's preferred "darwin" rather than gyp's preferred "mac"
    'NODE_PLATFORM="darwin"', # 👈
  ],
}],

[ 'OS=="solaris"', {
  'libraries': [
    '-lkstat',
    '-lumem',
  ],
  'defines!': [
    'NODE_PLATFORM="solaris"',
  ],
  'defines': [
    # we need to use node's preferred "sunos"
    # rather than gyp's preferred "solaris"
    'NODE_PLATFORM="sunos"', # 👈
  ],
}],

['OS == "zos"', {
  'defines': [
    '_XOPEN_SOURCE_EXTENDED',
    '_XOPEN_SOURCE=600',
    '_UNIX03_THREADS',
    '_UNIX03_WITHDRAWN',
    '_UNIX03_SOURCE',
    '_OPEN_SYS_SOCK_IPV6',
    '_OPEN_SYS_FILE_EXT=1',
    '_POSIX_SOURCE',
    '_OPEN_SYS',
    '_OPEN_SYS_IF_EXT',
    '_OPEN_SYS_SOCK_IPV6',
    '_OPEN_MSGQ_EXT',
    '_LARGE_TIME_API',
    '_ALL_SOURCE',
    '_AE_BIMODAL=1',
    '__IBMCPP_TR1__',
    'NODE_PLATFORM="os390"', # 👈
    'PATH_MAX=1024',
    '_ENHANCED_ASCII_EXT=0xFFFFFFFF',
    '_Export=extern',
    '__static_assert=static_assert',
  ],
  # -- ✂️ SNIP --
]

But what are the other possible values for this OS variable? We have to take a look at how GYP initializes that variable with a default value. It seems like all code paths call gyp.common.GetFlavor(params) somehow to get an initial OS name and then sometimes do custom configuration and initialization based on the return value (if win, if linux, if mac, etc.).

default_variables.setdefault("OS", gyp.common.GetFlavor(params))

The GetFlavor() function delegates to GetFlavorByPlatform()...

def GetFlavor(params):
    if "flavor" in params:
        return params["flavor"]

    defines = GetCompilerPredefines()
    if "__EMSCRIPTEN__" in defines:
        return "emscripten"
    if "__wasm__" in defines:
        return "wasi" if "__wasi__" in defines else "wasm"

    return GetFlavorByPlatform()

...which is where the real if sys.platform == "..." magic happens.

def GetFlavorByPlatform():
    """Returns |params.flavor| if it's set, the system's default flavor else."""
    flavors = {
        "cygwin": "win",
        "win32": "win",
        "darwin": "mac",
    }

    if sys.platform in flavors:
        return flavors[sys.platform]
    if sys.platform.startswith("sunos"):
        return "solaris"
    if sys.platform.startswith(("dragonfly", "freebsd")):
        return "freebsd"
    if sys.platform.startswith("openbsd"):
        return "openbsd"
    if sys.platform.startswith("netbsd"):
        return "netbsd"
    if sys.platform.startswith("aix"):
        return "aix"
    if sys.platform.startswith(("os390", "zos")):
        return "zos"
    if sys.platform == "os400":
        return "os400"

    return "linux"

All told, the returned flavor string can be "emscripten", "wasi", "wasm", "win", "mac", "solaris", "freebsd", "openbsd", "netbsd", "aix", "zos", "os400", "linux", or any other custom name set by params["flavor"].

So where does the Node.js build system set -DOS=<something>? Node.js doesn't use GYP directly, instead the official build procedure is to run ./configure and make -j4 (on Unix & macOS). The ./configure script is a /bin/sh script that reexecutes itself as a Python script and then imports ./configure.py if the Python version is satisfactory. That configure.py file is where the magic happens.

valid_os = ('win', 'mac', 'solaris', 'freebsd', 'openbsd', 'linux',
            'android', 'aix', 'cloudabi', 'os400', 'ios', 'openharmony')

parser.add_argument('--dest-os',
    action='store',
    dest='dest_os',
    choices=valid_os,
    help=f"operating system to build for ({', '.join(valid_os)})")

# determine the "flavor" (operating system) we're building for,
# leveraging gyp's GetFlavor function
flavor_params = {}
if options.dest_os:
  flavor_params['flavor'] = options.dest_os
flavor = GetFlavor(flavor_params)

^{Yes, it's the same gyp.common.GetFlavor() function}

This means that the OS when set manually (for cross compiling or whatever) must be one of 'win', 'mac', 'solaris', 'freebsd', 'openbsd', 'linux', 'android', 'aix', 'cloudabi', 'os400', 'ios', or 'openharmony'. But if it's not set at all (if options.dest_os is falsey) then it can be any of the possible return values from GetFlavor() with the knowledge that params["flavor"] is not set. GetCompilerPredefines() may still return __EMSCRIPTEN__, __wasm__, or __wasi__ though so we can't rule those out as impossible values. That means the total combined list is:

• "emscripten"
• "wasi"
• "wasm"
• "netbsd"
• "zos"
• "win"
• "mac"
• "solaris"
• "freebsd"
• "openbsd"
• "linux"
• "android"
• "aix"
• "cloudabi"
• "os400"
• "ios"
• "openharmony"

But some of these values, remember, have special mappings to Node.js NODE_PLATFORM values.

• zos becomes os390
• solaris becomes sunos
• mac becomes darwin
• win becomes win32

All together here's a list of all the possible Node.js NODE_PLATFORM (and by extension process.platform & friends) values with some usage numbers from a quick GitHub search:

• 0 matches "emscripten"
• 1 matches "wasi"
• 0 matches "wasm"
• 114 matches "netbsd"
• 284 matches "os390" ("zos" in GYP)
• 196 matches "win32" ("win" in GYP)
• 198 matches "darwin" ("mac" in GYP)
• 215 matches "sunos" ("solaris" in GYP)
• 211 matches "freebsd"
• 223 matches "openbsd"
• 148 matches "linux"
• 198 matches "android"
• 240 matches "aix"
• 0 matches "cloudabi" ^{Yes, really.}
• 1.1k matches "os400"
• 200 matches "ios"
• 229 matches "openharmony"

Note that a few of these values are extremely rare, but they are sort of possible depending on how you interpret "possible" in this situation.

node:process arch & node:os arch()

The first few layers of platform.arch are quite similar to node.platform; it's just sourced from a different macro NODE_ARCH, which is set in a different way.

// process.arch
READONLY_STRING_PROPERTY(process, "arch", per_process::metadata.arch);

And we know from the above process.platform investigation that per_process::metadata.arch is set to NODE_ARCH.

Metadata::Metadata() : arch(NODE_ARCH), platform(NODE_PLATFORM) {}

So where is this NODE_ARCH macro defined?

{
 'target_name': '<(node_core_target_name)',
 'type': 'executable',

 'defines': [
   'NODE_ARCH="<(target_arch)"', # 👈
   'NODE_PLATFORM="<(OS)"',
   'NODE_WANT_INTERNALS=1',
 ],
 # -- ✂️ SNIP --
}

host_arch = host_arch_win() if os.name == 'nt' else host_arch_cc()
target_arch = options.dest_cpu or host_arch
# ia32 is preferred by the build tools (GYP) over x86 even if we prefer the latter
# the Makefile resets this to x86 afterward
if target_arch == 'x86':
  target_arch = 'ia32'
# x86_64 is common across linuxes, allow it as an alias for x64
if target_arch == 'x86_64':
  target_arch = 'x64'
o['variables']['host_arch'] = host_arch
o['variables']['target_arch'] = target_arch # 👈

First, let's look at host_arch to see what possible values it could be.

def host_arch_win():
  """Host architecture check using environ vars (better way to do this?)"""

  observed_arch = os.environ.get('PROCESSOR_ARCHITECTURE', 'AMD64')
  arch = os.environ.get('PROCESSOR_ARCHITEW6432', observed_arch)

  matchup = {
    'AMD64'  : 'x64',
    'arm'    : 'arm',
    'mips'   : 'mips',
    'ARM64'  : 'arm64'
  }

  return matchup.get(arch, 'x64')

def host_arch_cc():
  """Host architecture check using the CC command."""

  if sys.platform.startswith('zos'):
    return 's390x'
  k = cc_macros(os.environ.get('CC_host'))

  matchup = {
    '__aarch64__' : 'arm64',
    '__arm__'     : 'arm',
    '__i386__'    : 'ia32',
    '__MIPSEL__'  : 'mipsel',
    '__mips__'    : 'mips',
    '__PPC64__'   : 'ppc64',
    '__PPC__'     : 'ppc64',
    '__x86_64__'  : 'x64',
    '__s390x__'   : 's390x',
    '__riscv'     : 'riscv',
    '__loongarch64': 'loong64',
  }

  rtn = 'ia32' # default

  for key, value in matchup.items():
    if k.get(key, 0) and k[key] != '0':
      rtn = value
      break

  if rtn == 'mipsel' and '_LP64' in k:
    rtn = 'mips64el'

  if rtn == 'riscv':
    if k['__riscv_xlen'] == '64':
      rtn = 'riscv64'
    else:
      rtn = 'riscv32'

  return rtn

^{cc_macros() returns all predefined C compiler macros as a dict}

host_arch_win() possible values: x64, arm, mips, arm64
host_arch_cc() possible values: s390x, arm64, arm, ia32, mipsel, mips, mips64el, ppc64, x64, riscv64, riscv32, loong64

Now let's look at what options are valid options.dest_cpu --dest-cpu values.

valid_arch = ('arm', 'arm64', 'ia32', 'mips', 'mipsel', 'mips64el',
              'ppc64', 'x64', 'x86', 'x86_64', 's390x', 'riscv64', 'loong64')

parser.add_argument('--dest-cpu',
    action='store',
    dest='dest_cpu',
    choices=valid_arch,
    help=f"CPU architecture to build for ({', '.join(valid_arch)})")

But x86 gets mapped to ia32 and x86_64 gets mapped to x64. Here's the logic flow. Note that some values that aren't allowed in --dest-cpu can sneak in if --dest-cpu isn't set and the arch is inferred from the environment.

host_arch = host_arch_win() if os.name == 'nt' else host_arch_cc()
# TYPE: "s390x" | "arm64" | "arm" | "ia32" | "mipsel" | "mips" | "mips64el" | "ppc64" | "x64" | "riscv64" | "riscv32" | "loong64"

target_arch = options.dest_cpu or host_arch
# TYPE: "x86" | "x86_64" | "s390x" | "arm64" | "arm" | "ia32" | "mipsel" | "mips" | "mips64el" | "ppc64" | "x64" | "riscv64" | "riscv32" | "loong64"

# ia32 is preferred by the build tools (GYP) over x86 even if we prefer the latter
# the Makefile resets this to x86 afterward
if target_arch == 'x86':
  target_arch = 'ia32'
# target_arch TYPE: "x86_64" | "s390x" | "arm64" | "arm" | "ia32" | "mipsel" | "mips" | "mips64el" | "ppc64" | "x64" | "riscv64" | "riscv32" | "loong64"

# x86_64 is common across linuxes, allow it as an alias for x64
if target_arch == 'x86_64':
  target_arch = 'x64'
# target_arch TYPE: "s390x" | "arm64" | "arm" | "ia32" | "mipsel" | "mips" | "mips64el" | "ppc64" | "x64" | "riscv64" | "riscv32" | "loong64"

o['variables']['host_arch'] = host_arch

# FINAL TYPE: "s390x" | "arm64" | "arm" | "ia32" | "mipsel" | "mips" | "mips64el" | "ppc64" | "x64" | "riscv64" | "riscv32" | "loong64"
o['variables']['target_arch'] = target_arch

So the final possible values for process.arch are the same as those possible for NODE_ARCH which are: "s390x", "arm64", "arm", "ia32", "mipsel", "mips", "mips64el", "ppc64", "x64", "riscv64", "riscv32", "loong64".

node:os machine()

os.machine() is a wrapper that returns the ...[3] property of the return value of internalBinding("os").getOSInformation().

module.exports = {
  // -- ✂️ SNIP --
  machine: getMachine,
};

const getMachine = () => machine;

const {
  0: type,
  1: version,
  2: release,
  3: machine,
} = _getOSInformation();

const {
  getAvailableParallelism,
  getCPUs,
  getFreeMem,
  getHomeDirectory: _getHomeDirectory,
  getHostname: _getHostname,
  getInterfaceAddresses: _getInterfaceAddresses,
  getLoadAvg,
  getPriority: _getPriority,
  getOSInformation: _getOSInformation, // 👈
  getTotalMem,
  getUserInfo,
  getUptime: _getUptime,
  isBigEndian,
  setPriority: _setPriority,
} = internalBinding('os');

That getOSInformation() C++ function sets ...[3] to info.machine which is set by uv_os_name().

static void GetOSInformation(const FunctionCallbackInfo<Value>& args) {
  Environment* env = Environment::GetCurrent(args);
  uv_utsname_t info;
  int err = uv_os_uname(&info);

  if (err != 0) {
    CHECK_GE(args.Length(), 1);
    USE(env->CollectUVExceptionInfo(
        args[args.Length() - 1], err, "uv_os_uname"));
    return;
  }

  // [sysname, version, release, machine]
  Local<Value> osInformation[4];
  if (String::NewFromUtf8(env->isolate(), info.sysname)
          .ToLocal(&osInformation[0]) &&
      String::NewFromUtf8(env->isolate(), info.version)
          .ToLocal(&osInformation[1]) &&
      String::NewFromUtf8(env->isolate(), info.release)
          .ToLocal(&osInformation[2]) &&
      String::NewFromUtf8(env->isolate(), info.machine) // 👈
          .ToLocal(&osInformation[3])) {
    args.GetReturnValue().Set(
        Array::New(env->isolate(), osInformation, arraysize(osInformation)));
  }
}

uv_os_name() has two different implementations: one for Unix and one for Windows. The Unix implementation uses uname() .machine.

int uv_os_uname(uv_utsname_t* buffer) {
  struct utsname buf;
  int r;

  if (buffer == NULL)
    return UV_EINVAL;

  if (uname(&buf) == -1) {
    r = UV__ERR(errno);
    goto error;
  }

  // -- ✂️ SNIP --

#if defined(_AIX) || defined(__PASE__)
  r = uv__strscpy(buffer->machine, "ppc64", sizeof(buffer->machine));
#else
  r = uv__strscpy(buffer->machine, buf.machine, sizeof(buffer->machine));
#endif

  if (r == UV_E2BIG)
    goto error;

  return 0;

error:
  buffer->sysname[0] = '\0';
  buffer->release[0] = '\0';
  buffer->version[0] = '\0';
  buffer->machine[0] = '\0';
  return r;
}

So the possible values are whatever uname() .machine can be plus ppc64 if it's AIX or __PASE__ (whatever that is). But what are the possible values of uname() .machine? That's a good question... for another time. ^{TODO: Investigate the possible values of uname -m}

Back to uv_os_name(). The Windows implementation sets the .machine property to a variety of static strings depending on some conditions.

int uv_os_uname(uv_utsname_t* buffer) {
  /* Implementation loosely based on
     https://github.com/gagern/gnulib/blob/master/lib/uname.c */
  OSVERSIONINFOW os_info;
  SYSTEM_INFO system_info;
  HKEY registry_key;
  WCHAR product_name_w[256];
  DWORD product_name_w_size;
  size_t version_size;
  int processor_level;
  int r;

  // -- ✂️ SNIP --

  /* Populate the machine field. */
  GetSystemInfo(&system_info);

  switch (system_info.wProcessorArchitecture) {
    case PROCESSOR_ARCHITECTURE_AMD64:
      uv__strscpy(buffer->machine, "x86_64", sizeof(buffer->machine));
      break;
    case PROCESSOR_ARCHITECTURE_IA64:
      uv__strscpy(buffer->machine, "ia64", sizeof(buffer->machine));
      break;
    case PROCESSOR_ARCHITECTURE_INTEL:
      uv__strscpy(buffer->machine, "i386", sizeof(buffer->machine));

      if (system_info.wProcessorLevel > 3) {
        processor_level = system_info.wProcessorLevel < 6 ?
                          system_info.wProcessorLevel : 6;
        buffer->machine[1] = '0' + processor_level;
      }

      break;
    case PROCESSOR_ARCHITECTURE_IA32_ON_WIN64:
      uv__strscpy(buffer->machine, "i686", sizeof(buffer->machine));
      break;
    case PROCESSOR_ARCHITECTURE_MIPS:
      uv__strscpy(buffer->machine, "mips", sizeof(buffer->machine));
      break;
    case PROCESSOR_ARCHITECTURE_ALPHA:
    case PROCESSOR_ARCHITECTURE_ALPHA64:
      uv__strscpy(buffer->machine, "alpha", sizeof(buffer->machine));
      break;
    case PROCESSOR_ARCHITECTURE_PPC:
      uv__strscpy(buffer->machine, "powerpc", sizeof(buffer->machine));
      break;
    case PROCESSOR_ARCHITECTURE_SHX:
      uv__strscpy(buffer->machine, "sh", sizeof(buffer->machine));
      break;
    case PROCESSOR_ARCHITECTURE_ARM:
      uv__strscpy(buffer->machine, "arm", sizeof(buffer->machine));
      break;
    default:
      uv__strscpy(buffer->machine, "unknown", sizeof(buffer->machine));
      break;
  }

  return 0;

error:
  buffer->sysname[0] = '\0';
  buffer->release[0] = '\0';
  buffer->version[0] = '\0';
  buffer->machine[0] = '\0';
  return r;
}

All possible values are: x86_64, ia64, i386, i486, i586, i686, mips, alpha, powerpc, sh, arm, unknown.

So the possible values are well-known on Windows (yay), but very varied on Unix systems (not yay). This post is already too long; I'm not going to investigate all uname -m possible values, too. Maybe another time.

• Deno.build.os
• Deno.build.arch
• Deno.build.target
• node:process platform & node:os platform()
• node:process arch & node:os arch()
• node:os machine()

Note that the node:-related values that I'm discussing are for Deno's Node.js API polyfills, not the Node.js' implementation of them. That's another deep dive that I might explore later. This is just Deno's platform/arch values -- where and how they are exposed to JS code.

TL;DR:

• Deno.build.os is any possible OS name across all valid Rust targets
• Deno.build.arch is any possible arch name across all valid Rust targets
• Deno.build.target is any valid Rust target tuple
• process.platform is any possible OS name across all valid Rust targets but replace windows with win32
• process.arch is "x64" | "arm64" | "riscv64" only; it throws an Error when run on any other arch
• os.machine() is any possible arch name across all valid Rust targets but replace aarch64 with arm64

⚠️ Remember! These are the possible values for Deno's Node.js node: polyfills, not for Node.js' own implementation.

Deno.build

There's this Deno.build object. It's configured with default values.

const build = {
  target: "unknown",
  arch: "unknown",
  os: "unknown",
  vendor: "unknown",
  env: undefined,
};

There's a setBuildInfo() function...

function setBuildInfo(target) {
  const { 0: arch, 1: vendor, 2: os, 3: env } = StringPrototypeSplit(
    target,
    "-",
    4,
  );
  build.target = target;
  build.arch = arch;
  build.vendor = vendor;
  build.os = os;
  build.env = env;
  ObjectFreeze(build);
}

...which is exposed as Deno.core.setBuildInfo().

// Extra Deno.core.* exports
const core = ObjectAssign(globalThis.Deno.core, {
  build,
  setBuildInfo, // 👈
  registerErrorBuilder,
  buildCustomError,
  registerErrorClass,
  setUpAsyncStub,
  hasPromise,
  promiseIdSymbol,
});

Since this function is now exposed, it can be called from elsewhere.

function runtimeStart(
  denoVersion,
  v8Version,
  tsVersion,
  target,
) {
  core.setWasmStreamingCallback(fetch.handleWasmStreaming);
  core.setReportExceptionCallback(event.reportException);
  op_set_format_exception_callback(formatException);
  version.setVersions(
    denoVersion,
    v8Version,
    tsVersion,
  );
  core.setBuildInfo(target); // 👈
}

Where does this runtimeStart() function get called? In the same file.

runtimeStart(
  denoVersion,
  v8Version,
  tsVersion,
  target,
);

But where does that target variable come from? op_snapshot_options().

const {
  tsVersion,
  v8Version,
  target,
} = op_snapshot_options();

But where does that come from? It's imported from ext:core/ops...

import {
  op_bootstrap_args,
  op_bootstrap_is_from_unconfigured_runtime,
  op_bootstrap_no_color,
  op_bootstrap_pid,
  op_bootstrap_stderr_no_color,
  op_bootstrap_stdout_no_color,
  op_get_ext_import_meta_proto,
  op_internal_log,
  op_main_module,
  op_ppid,
  op_set_format_exception_callback,
  op_snapshot_options, // 👈
  op_worker_close,
  op_worker_get_type,
  op_worker_post_message,
  op_worker_recv_message,
  op_worker_sync_fetch,
} from "ext:core/ops";

...which is defined in deno_core.

// Note: Called at snapshot time, op perf is not a concern.
#[op2]
#[serde]
pub fn op_snapshot_options(state: &mut OpState) -> SnapshotOptions {
  #[cfg(feature = "hmr")]
  {
    state.try_take::<SnapshotOptions>().unwrap_or_default()
  }
  #[cfg(not(feature = "hmr"))]
  {
    state.take::<SnapshotOptions>()
  }
}

But what's that SnapshotOptions?

#[derive(Serialize)]
#[serde(rename_all = "camelCase")]
pub struct SnapshotOptions {
  pub ts_version: String,
  pub v8_version: &'static str,
  pub target: String, // 👈
}

Where does the actual target string come from? Before we get to the Default implementation for SnapshotOptions, let's look at where else it's constructed. There's a manifest-like extension definition macro that defines a deno_bootstrap extension. It takes in a SnapshotOptions struct.

deno_core::extension!(
  deno_bootstrap,
  ops = [
    op_bootstrap_args,
    op_bootstrap_pid,
    op_bootstrap_numcpus,
    op_bootstrap_user_agent,
    op_bootstrap_language,
    op_bootstrap_log_level,
    op_bootstrap_color_depth,
    op_bootstrap_no_color,
    op_bootstrap_stdout_no_color,
    op_bootstrap_stderr_no_color,
    op_bootstrap_unstable_args,
    op_bootstrap_is_from_unconfigured_runtime,
    op_snapshot_options,
  ],
  options = {
    snapshot_options: Option<SnapshotOptions>, // 👈
    is_from_unconfigured_runtime: bool,
  },
  state = |state, options| {
    if let Some(snapshot_options) = options.snapshot_options {
      state.put::<SnapshotOptions>(snapshot_options); // 👈
    }
    state.put(IsFromUnconfiguredRuntime(options.is_from_unconfigured_runtime));
  },
);

I'll be honest, I don't know what the type of state is or what its lifecycle is. Somehow, though, state must be populated with a SnapshotOptions since it gets .take()-en in the op_snapshot_options() function above (sometimes with a default value via .unwrap_or_default()). But where does this extension get initialized with a SnapshotOptions struct? In the common_extensions() convenience function that initializes and returns a bunch of -- you guessed it -- common extensions.

fn common_extensions<
  TInNpmPackageChecker: InNpmPackageChecker + 'static,
  TNpmPackageFolderResolver: NpmPackageFolderResolver + 'static,
  TExtNodeSys: ExtNodeSys + 'static,
>(
  has_snapshot: bool,
  unconfigured_runtime: bool,
) -> Vec<Extension> {
  // NOTE(bartlomieju): ordering is important here, keep it in sync with
  // `runtime/worker.rs`, `runtime/web_worker.rs`, `runtime/snapshot_info.rs`
  // and `runtime/snapshot.rs`!
  vec![
    // -- ✂️ SNIP --
    ops::bootstrap::deno_bootstrap::init(
      has_snapshot.then(Default::default), // 👈
      unconfigured_runtime,
    ),
    // -- ✂️ SNIP --
  ]
}

There's also this snapshotting thing that seems to happen at build time, which probably magically bakes in the snapshot options somehow? I'm not really sure. All I know is that these options are somehow stashed and retrieved by the Deno runtime. 🤷

let snapshot_options = SnapshotOptions {
  ts_version: shared::TS_VERSION.to_string(),
  v8_version: deno_runtime::deno_core::v8::VERSION_STRING,
  target: std::env::var("TARGET").unwrap(),
};

There's also the default implementation, which uses the Rust-provided compile-time OS/arch constants to reconstruct the likely target triple string.

impl Default for SnapshotOptions {
  fn default() -> Self {
    let arch = std::env::consts::ARCH;
    let platform = std::env::consts::OS;
    let target = match platform {
      "macos" => format!("{}-apple-darwin", arch),
      "linux" => format!("{}-unknown-linux-gnu", arch),
      "windows" => format!("{}-pc-windows-msvc", arch),
      rest => format!("{}-{}", arch, rest),
    };

    Self {
      ts_version: "n/a".to_owned(),
      v8_version: deno_core::v8::VERSION_STRING,
      target,
    }
  }
}

So that Deno.build.target value (which is obtained from Rust via op_snapshot_options()) is what the rest of the Deno.build object's properties are based on. It's is either passed in at build time via snapshotting or reconstructed from the Rust-provided information at runtime.

let target = std::env::var("TARGET").unwrap();

let target = match std::env::consts::OS {
  "macos" => format!("{}-apple-darwin", std::env::consts::ARCH),
  "linux" => format!("{}-unknown-linux-gnu", std::env::consts::ARCH),
  "windows" => format!("{}-pc-windows-msvc", std::env::consts::ARCH),
  rest => format!("{}-{}", std::env::consts::ARCH, rest),
};

So that's every Rust target tuple that Deno happens to successfully compile on. I don't know how long a list that is.

The targets that Deno provides official releases for (as of Deno v2.6.0) are:

• aarch64-apple-darwin
• aarch64-unknown-linux-gnu
• x86_64-apple-darwin
• x86_64-pc-windows-msvc
• x86_64-unknown-linux-gnu

Deno.build.os

So the final verdict is that Deno.build.os is derived from the third component of a <arch>-<vendor>-<os>-<env> target tuple which means that Deno.build.os would be darwin, linux, or windows unless Deno is compiled for another target (which is possible). The official Deno docs for Deno.build.os state that its type is "darwin" | "linux" | "android" | "windows" | "freebsd" | "netbsd" | "aix" | "solaris" | "illumos".

Deno.build.arch

The Deno.build.arch value is a similar story. Given the official targets, the first arch component can be either aarch64 or x86_64. Other architectures like riscv64gc might successfully compile for all I know. The docs say that Deno.build.arch's type is "aarch64" | "x86_64".

node:process platform & node:os platform()

Deno's node:os platform() function is just a wrapper around process.platform.

/** Returns the a string identifying the operating system platform. The value is set at compile time. Possible values are 'darwin', 'linux', and 'win32'. */
export function platform(): string {
  return process.platform;
}

Deno's node:process platform (or process.platform) is a variable...

export let platform = isWindows ? "win32" : ""; // initialized during bootstrap

/** https://nodejs.org/api/process.html#process_process_platform */
Object.defineProperty(process, "platform", {
  get() {
    return platform;
  },
});

...that's initialized at bootstrapping time to the value of Deno.build.os. Unless isWindows is true; then it's set to win32 (not windows).

// Should be called only once, in `runtime/js/99_main.js` when the runtime is
// bootstrapped.
internals.__bootstrapNodeProcess = function (
  argv0Val: string | undefined,
  args: string[],
  denoVersions: Record<string, string>,
  nodeDebug: string,
  warmup = false,
) {
    // -- ✂️ SNIP --
    arch = arch_();
    platform = isWindows ? "win32" : Deno.build.os; // 👈
    pid = Deno.pid;
    ppid = Deno.ppid;
    initializeDebugEnv(nodeDebug);
    // -- ✂️ SNIP --
};

So what's this isWindows thing? It's pretty self-explanatory, but let's investigate anyway.

import { isAndroid, isWindows } from "ext:deno_node/_util/os.ts";

// -- Some parts ✂️snipped for brevity --
import { op_node_build_os } from "ext:core/ops";
export const osType: OSType = op_node_build_os();
export const isWindows = osType === "windows";

#[op2]
#[string]
fn op_node_build_os() -> String {
  env!("TARGET").split('-').nth(2).unwrap().to_string()
}

A Rust TARGET string is <arch>-<vendor>-<os>-<env>. op_node_build_os() just returns the os part of that tuple. It seems like it's the same value as Deno.build.os, just retrieved a bit differently. I'm not really sure why Deno.build.os wasn't used. Maybe there's a good reason. 🤷

So that means that process.platform/os.platform() is the same value as Deno.build.os except it's win32 instead of windows. That's a string value of darwin, linux, win32, or any other valid Rust target OS name.

node:process arch & node:os arch()

Deno's node:os arch() polyfill is just a wrapper around node:process arch.

export function arch(): string {
  return process.arch;
}

Deno's node:process arch (or process.arch) is a variable...

export let arch = "";

/** https://nodejs.org/api/process.html#process_process_arch */
Object.defineProperty(process, "arch", {
  get() {
    return arch;
  },
});

...that's initialized at bootstrapping time to the result of an internal arch() getter.

// Should be called only once, in `runtime/js/99_main.js` when the runtime is
// bootstrapped.
internals.__bootstrapNodeProcess = function (
  argv0Val: string | undefined,
  args: string[],
  denoVersions: Record<string, string>,
  nodeDebug: string,
  warmup = false,
) {
    // -- ✂️ SNIP --
    arch = arch_(); // 👈
    platform = isWindows ? "win32" : Deno.build.os;
    pid = Deno.pid;
    ppid = Deno.ppid;
    initializeDebugEnv(nodeDebug);
    // -- ✂️ SNIP --
};

import {
  arch as arch_, // 👈
  chdir,
  cwd,
  env,
  nextTick as _nextTick,
  version,
  versions,
} from "ext:deno_node/_process/process.ts";

That arch() getter is a very well-defined and limited function that throws an error on all but three architectures.

/** Returns the operating system CPU architecture for which the Deno binary was compiled */
export function arch(): string {
  if (build.arch == "x86_64") {
    return "x64";
  } else if (build.arch == "aarch64") {
    return "arm64";
  } else if (build.arch == "riscv64gc") {
    return "riscv64";
  } else {
    throw new Error("unreachable");
  }
}

Therefore, the exact guaranteed type for node:process arch or node:os arch() in Deno is "x64" | "arm64" | "riscv64". This is far more limited than Node.js' implementation of these APIs.

Possible values are 'arm', 'arm64', 'ia32', 'loong64', 'mips', 'mipsel', 'ppc64', 'riscv64', 's390x', and 'x64'. The return value is equivalent to process.arch.

— Node.js node:os arch() docs

node:os machine()

machine() is just Deno.build.arch with aarch64 mapped to arm64 instead.

/** Returns the machine type as a string */
export function machine(): string {
  if (Deno.build.arch == "aarch64") {
    return "arm64";
  }

  return Deno.build.arch;
}

The full type is probably "arm64" | "x86_64" | "riscv64gc" but it could have more possible values.

Ingredients

There's two parts: the main apple part and the topping powdery sprinkle part.

The main apple part:

Peel and cut up the apple into chunks. We use an apple corer & spiral slicer with a hand crank. It works well.

• 4c sliced apples

The topping:

• 1/3 cup brown sugar
• 1/2 cup gluten-free flour
• 1/2 cup oats
• 1/3 cup shortening
• 1 tsp cinnamon
• 1 tsp nutmeg

Pan: 8x8 inch. Use glass.
Oven: 375°F (190°C) for 30 minutes. "Golden brown" on top.

Instructions

1. Grease pan.
2. Place apples in pan. Use more or less apples to fill pan.
3. Use pastry cutter thing (biscuit masher) to mix topping ingredients into shortening crumbly bits.
4. Sprinkle topping on top.
5. Bake it.

• 1 1/4 cups water
• 2 Tbsp butter
• 3 1/3 cups bread flour
• 2 Tbsp dry milk
• 1 1/2 Tbsp sugar
• 1 1/4 tsp salt
• 2 tsp active dry yeast

1. Put the water in.
2. Add everything except the yeast. Make into a flat landmass so that there's no exposed water for the yeast to touch.
3. Make a depression for the yeast to sit.
4. Add the yeast into the depression.
5. Start the bread maker on "regular" settings.

• 1 egg
• 1c sugar
• 1c peanut butter

Oven: 350°F (175°C) for 12-15 minutes

1. Mix everything in a mixer machine.
2. Bake it.

This recipe is in two parts: wet step and dry step.

Use a large 6 cup or more glass mixing bowl. Stuff is going in the microwave.

Wet step

• 2 Tbsp oil
• 1/2 cup honey
• 2/3 cup peanut butter

1. Use a liquid measure. Place oil in the cup first. Coat the sides.
2. Add honey using the graduations on the liquid measure. No extra measuring cup needed.
3. Pour into the big glass bowl.
4. Use a 2/3 cup dry measure for the peanut butter. Spatula recommended.
5. Microwave for 30 seconds.
6. Stir.

Dry step

• 3 cups oats
• 1 cup flax meal
• 3/4 cup plus a bit coconut flakes

Pan: 9x13 metal cake pan
Oven: 350°F (175°C) for 11-14 minutes

1. Add everything.
2. Mix. Use smooshing compacting motions to get sticky stuff everywhere.
3. Bake it.

• Avocados
• Tomato bits
• A bit of raw onion bits
• Lime juice
• Garlic or garlic powder
• Salt & pepper
• Any other seasonings you like i.e. spicy powder or hot sauce

For 4 people use about 2 avocados and 2 roma tomatoes.

• 1/2 cup sugar
• 1/2 cup brown sugar
• 1/2 cup peanut butter
• 1/4 cup shortening
• 1/4 cup butter (softened)
• 1 egg
• 1 1/4 cups all-purpose flour
• 3/4 tsp baking soda
• 1/2 tsp baking powder

Oven: 350°F (175°C) for 10-12 minutes

1. Mix everything. Use a mixer machine.
2. Bake it.
3. Let cookies cook on the pan after coming out of the oven.

I like these cookies.

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <meta http-equiv="refresh" content="0; url=DEST_ROOT_URL" />
    <meta name="robots" content="noindex" />
    <title>Moved to DEST_ROOT_URL</title>
    <script>
      location.replace("DEST_ROOT_URL" + location.toString().slice(origin.length));
    </script>
  </head>
  <body>
    <p>
      Moved to <a href="DEST_ROOT_URL">DEST_ROOT_URL</a>
    </p>
  </body>
</html>

Where DEST_ROOT_URL is the destination URL root without the trailing slash since origin doesn't include the trailing slash.

The trick is the JavaScript in the 404.html page which is rendered when a URL is not found anywhere in your GitHub Pages site. The <script> tag is in <head> so it should run before the page is even shown. It replaces (no back-button history entry) the current URL with the one you give it. In this case that's the current URL (location.toString()) minus the https://example.com prefix (.slice(origin.length)) with the destination URL prepended to it.

For example:

1. Navigate to https://example.org/hello-world
2. 404, serve 404.html
3. "https://example.org/hello-world".slice("https://example.org".length)
4. location.replace("https://example.com" + $3)