import.meta.runtime

[guybedford]

The runtime keys gives useful information about the environment to the resolver, but there is currently no way to inspect this information from within the runtime environment.

I understand this proposal is moving to a more general package.json spec, but before we do that, I wanted to discuss the possibility of an import.meta.runtime object which would expose a frozen bag of booleans corresponding to the runtime key environment.

Would be useful for platform checks:

if (import.meta.runtime.node) { ... }

As well as dev / production checks:

if (import.meta.runtime?.development) { ... }

Having a standard like this would get support between Node.js and tools - of course we can't get support in browsers, but that might be acceptable having this as a build time inlining. And perhaps the browser does even define import.meta.runtime = { browser: true } one day.

[JakobJingleheimer]

I like this. But not ….runtime.node. If we could have a not-insane version of user agent, that would be great. It doesn't necessarily need to be so specific as to identify the UA, but server vs browser could save a lot of headache. And a standardise replacement for NODE_ENV 🥹 basically a lot of what is on node:process could be well standardised.

[guybedford]

The nice thing about the runtime.node definition is that it follows the clearly defined meaning of the runtime keys which are already specified. User agents are notorious for backwards compat. For example Deno wants to present itself as Node.js these days so is actually using the node condition set to true - so would get runtime.node === true and runtime.deno === true which is sensible and a better way of handling the "every user agent eventually copies Chrome's structure" problem.

[hybrist]

As well as dev / production checks:

I assume this would expand the definition of "runtime keys" which currently is only a subset of "conditions"?

[guybedford]

Good point - perhaps this is wider in scope than runtime keys then. The question then would be where to specify this in WinterTC though...

[pi0]

For example Deno wants to present itself as Node.js these days so is actually using the node condition set to true - so would get runtime.node === true and runtime.deno === true which is sensible and a better way of handling the "every user agent eventually copies Chrome's structure" problem.

Other runtimes being able to tell they are "like" Node.js, can be both beneficial (in a way libraries can then depend on Node.js APIs) but also very confusing in other use cases when actually libraries need to check "real" Node.js (to depend on native bindings for example). unjs/std-env#100 for reference, we used to have flags like isNode === true (~runtime.meta.node) which got the interpretation much harder vs runtime === "node" that is now preferred

May I suggest that we split this into two proposals:

• Runtimes to strictly flag their "identity"/name (something like runtime keys)
• Runtimes to flag their "compatibility" (something like current proposal, as multiple flags or UA-like, I think flags like this are better also for build-tools and static analyzes)

[guybedford]

@pi0 how would the described split you mention handle development and production conditions? We could solve that issue separately as well and just specify an import.meta.development or import.meta.production, but it's nice to get other resolution conditions "for free". Perhaps a different scoping is the way to go though.

[pi0]

import.meta.development + import.meta.production are special in that they are mutually exclusive, explicit and orderless flags.

Conditions like node, deno, workerd, web need to be either explicit (import.meta.runtime.name: "deno" for example or at least specified in order like import.meta.runtime.compatibility: ["deno", "node"]

[ljharb]

I'm very confused why we'd want to effectively replicate the useragent nightmare of the web, on the server. A world in which "node" is true, but it's not node, does not sound like a good one - nor does a world where people are explicitly writing code intended for node, but it still runs on "not node", potentially doing the wrong thing. (replace "node" with any other runtime, same applies)

What are the concrete use cases here that can't be solved by actual feature detection?

[hybrist]

I have seen an unfortunate number of packages/guides using conditions "wrong", e.g. doing {node, default} instead of {browser, default} which is more likely to work. So now deno/bun need to work around those packages somehow.

[guybedford]

There are two separate use cases here:

1. A universal replacement for the process.env.NODE_ENV === 'production' check which is Node.js specific and a pattern which is common in the npm ecosystem which should ideally have a cross-platform replacement
2. A "runtime" runtime keys lookup - making information available to the resolver available to users. For example fastly is a runtime key for the Fastly platform, and we wouldn't need to design our own user agent to be able to support checking if you are on the already-defined Fastly runtime key at runtime.

(1) is the primary use case I am personally seeking to solve here right now - so we could separately specify a universal import.meta.development or import.meta.production, but it's worth going through the discussion on a more general conditions runtime bag of bools since this is already standardized what those key definitions would be.

[jedwards1211]

If you go down that road then it expands the concept of import conditions rather broadly, from something specific to changing module resolution, to a hard-to-define concept of ambient static flags about the build/runtime environment

[ljharb]

@jkrems and i'd have hoped that the lesson we learned from the web is, you shouldn't work around them, you should evangelize them to do things properly instead, before the problem gets too widespread.

[jedwards1211]

some kind of flags about the runtime or build-time environment seem necessary but it doesn't seem quite right for them to live under import since some flags may have nothing to do with module resolution

[hybrist]

@jkrems and i'd have hoped that the lesson we learned from the web is, you shouldn't work around them, you should evangelize them to do things properly instead, before the problem gets too widespread.

I agree!

Although I'll also add that "working by default" beats "evangelizing and making everybody pick correctly". Which is why I would strongly recommend not having both production and development if such an API is added but only a development condition. (Longer reasoning in https://github.com/jkrems/md/blob/main/import-meta-debug.md)