feat: add node process.env builtin to access env vars

[sd2k]

This uses wasi:cli/environment to get the environment variables provided by the host. The process.env object is a Proxy in this implementation so that we can call get_environment lazily, which enables wizer to run.

I needed this for a PoC so had Cursor help me out (it was surprisingly good) - it's probably not exactly the direction you want but I'm happy to iterate if it's in the right direction!

I think this relates to #188?

[squillace]

Hey, @andreiltd and I need this just like anyone will. Can't run in production without env vars for creds among other things and they can't be baked into the component, obvs. :-)

We'll see about having a look next week some time.

[andreiltd]

Thank you for the patch! We had a brief discussion about it during the last JS SIG community meeting. While the functionality is definitely useful, adding just this small portion of the Node API as a built‑in doesn’t feel quite right at this stage.

A fully supported and currently working alternative for accessing environment variables with both componentize-js and jco is to use the WASI environment API. For example:

import { getEnvironment } from 'wasi:cli/[email protected]';

const entries = getEnvironment();
const env = Object.fromEntries(entries);

console.log(env.FOO);

Let us know if you'd like help adapting your use case to this approach.

[rajsite]

I'm also interested in having process.env as a built-in similar to having fetch-event. Those two features as a subset of "common js apis" cover a large portion of http proxy for building "useful things", i.e. respond to http requests and access secrets through env.

Covering fetch-event and process.env let you leverage hono web framework, and pretty sophisticated workflows via oauth-providers and oidc-auth.

Those two features I'd argue are the minimum for a useful production workflow (respond to http requests and not hard code secrets) and by supporting them as built-ins lowers the new user barrier to entry quite a bit. You can make production useful tools without having to take on the cognitive load of understanding wasi imports, etc. and opt-in to those for more advanced workflows.

Is there active opposition to supporting process.env as a subset of node apis or would that contribution be welcome?