Add documentation for importable env from cloudflare:workers

Document the import { env } from 'cloudflare:workers' API across
Workers documentation pages that discuss environment variables,
secrets, and bindings access patterns.

Updates:
- environment-variables.mdx: Add section on importing env globally
- secrets.mdx: Show importable env as an access method with example
- process.mdx: Add alternative to process.env using cloudflare:workers
- fetch.mdx: Cross-reference importable env in env parameter docs
- migrate-to-module-workers.mdx: Show importable env for ES modules

Author: elithrar

src/content/docs/workers/configuration/environment-variables.mdx

@@ -5,7 +5,7 @@ head: []
 description: You can add environment variables, which are a type of binding, to attach text strings or JSON values to your Worker.
 ---
 
-import { Render, TabItem, Tabs, WranglerConfig, DashButton } from "~/components";
+import { Render, TabItem, Tabs, TypeScriptExample, WranglerConfig, DashButton } from "~/components";
 
 ## Background
 
@@ -47,6 +47,34 @@ export default {
 
 </TabItem> </Tabs>
 
+### Import `env` for global access
+
+You can also import `env` from [`cloudflare:workers`](/workers/runtime-apis/bindings/#importing-env-as-a-global) to access environment variables from anywhere in your code, including outside of request handlers:
+
+<TypeScriptExample>
+
+```ts
+import { env } from "cloudflare:workers";
+
+// Access environment variables at the top level
+const apiHost = env.API_HOST;
+
+export default {
+	async fetch(request: Request): Promise<Response> {
+		return new Response(`API host: ${apiHost}`);
+	},
+};
+```
+
+</TypeScriptExample>
+
+This approach is useful when you need to:
+
+- Initialize configuration or API clients at the top level of your Worker.
+- Access environment variables from deeply nested functions without passing `env` through every function call.
+
+For more details, refer to [Importing `env` as a global](/workers/runtime-apis/bindings/#importing-env-as-a-global).
+
 ### Configuring different environments in Wrangler
 
 [Environments in Wrangler](/workers/wrangler/environments) let you specify different configurations for the same Worker, including different values for `vars` in each environment.
@@ -102,13 +130,7 @@ Select the **Secret** type if your environment variable is a [secret](/workers/c
 
 ## Environment variables and Node.js compatibility
 
-When you enable both the [`nodejs_compat`](/workers/runtime-apis/nodejs/) and
-[`nodejs_compat_populate_process_env`](/workers/configuration/compatibility-flags/#nodejs_compat_populate_process_env)
-compatibility flags, and the `disallow_importable_env` compatibility flag is
-not set, environment variables will also be available via the global
-`process.env`. Note that the `nodejs_compat_populate_process_env` flag is
-enabled automatically when `nodejs_compat` is used with a compatibility date
-on or after April 1st, 2025.
+When you enable [`nodejs_compat`](/workers/runtime-apis/nodejs/) and the [`nodejs_compat_populate_process_env`](/workers/configuration/compatibility-flags/#nodejs_compat_populate_process_env) compatibility flag (enabled by default for compatibility dates on or after 2025-04-01), environment variables are available via the global `process.env`.
 
 The `process.env` will be populated lazily the first time that `process` is accessed
 in the worker.

src/content/docs/workers/configuration/secrets.mdx

@@ -5,15 +5,21 @@ head: []
 description: Store sensitive information, like API keys and auth tokens, in your Worker.
 ---
 
-import { Render,DashButton } from "~/components";
+import { Render, DashButton, TypeScriptExample } from "~/components";
 
 ## Background
 
-Secrets are a type of binding that allow you to attach encrypted text values to your Worker. Secrets are used for storing sensitive information like API keys and auth tokens. Secrets are programmatically available on the [`env` parameter](/workers/runtime-apis/handlers/fetch/#parameters) passed to your Worker's [`fetch` event handler](/workers/runtime-apis/handlers/fetch/), and may also be accessible via [`process.env`](/workers/configuration/environment-variables) in Workers that support Node.js compatibility.
+Secrets are a type of binding that allow you to attach encrypted text values to your Worker. Secrets are used for storing sensitive information like API keys and auth tokens.
+
+You can access secrets in your Worker code through:
+
+- The [`env` parameter](/workers/runtime-apis/handlers/fetch/#parameters) passed to your Worker's [`fetch` event handler](/workers/runtime-apis/handlers/fetch/).
+- Importing `env` from [`cloudflare:workers`](/workers/runtime-apis/bindings/#importing-env-as-a-global) to access secrets from anywhere in your code.
+- [`process.env`](/workers/configuration/environment-variables) in Workers that have [Node.js compatibility](/workers/runtime-apis/nodejs/) enabled.
 
 ## Access your secrets with Workers
 
-Secrets can be accessed from Workers as you would any other [environment variables](/workers/configuration/environment-variables/). For instance, given a `DB_CONNECTION_STRING` secret, you can access it in your Worker code:
+Secrets can be accessed from Workers as you would any other [environment variables](/workers/configuration/environment-variables/). For instance, given a `DB_CONNECTION_STRING` secret, you can access it in your Worker code through the `env` parameter:
 
 ```js title="index.js"
 import postgres from "postgres";
@@ -31,6 +37,32 @@ export default {
 };
 ```
 
+You can also import `env` from `cloudflare:workers` to access secrets from anywhere in your code, including outside of request handlers:
+
+<TypeScriptExample>
+
+```ts
+import { env } from "cloudflare:workers";
+import postgres from "postgres";
+
+// Initialize the database client at the top level using a secret
+const sql = postgres(env.DB_CONNECTION_STRING);
+
+export default {
+	async fetch(request: Request): Promise<Response> {
+		const result = await sql`SELECT * FROM products;`;
+
+		return new Response(JSON.stringify(result), {
+			headers: { "Content-Type": "application/json" },
+		});
+	},
+};
+```
+
+</TypeScriptExample>
+
+For more details on accessing `env` globally, refer to [Importing `env` as a global](/workers/runtime-apis/bindings/#importing-env-as-a-global).
+
 :::note[Secrets Store (beta)]
 Secrets described on this page are defined and managed on a per-Worker level. If you want to use account-level secrets, refer to [Secrets Store](/secrets-store/). Account-level secrets are configured on your Worker as a [Secrets Store binding](/secrets-store/integrations/workers/).
 :::

src/content/docs/workers/reference/migrate-to-module-workers.mdx

@@ -6,7 +6,7 @@ description: Write your Worker code in ES modules syntax for an optimized experi
 
 ---
 
-import { WranglerConfig } from "~/components";
+import { WranglerConfig, TypeScriptExample } from "~/components";
 
 This guide will show you how to migrate your Workers from the [Service Worker](https://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API) format to the [ES modules](https://blog.cloudflare.com/workers-javascript-modules/) format.
 
@@ -177,7 +177,7 @@ addEventListener("fetch", async (event) => {
 
 ### Environment variables in ES modules format
 
-In ES modules format, environment variables are only available inside the `env` parameter that is provided at the entrypoint to your Worker application.
+In ES modules format, environment variables are available through the `env` parameter provided at the entrypoint to your Worker application:
 
 ```js
 export default {
@@ -188,6 +188,28 @@ export default {
 };
 ```
 
+You can also import `env` from `cloudflare:workers` to access environment variables from anywhere in your code, including the top-level scope:
+
+<TypeScriptExample>
+
+```ts
+import { env } from "cloudflare:workers";
+
+// Access environment variables at the top level
+const accountId = env.API_ACCOUNT_ID;
+
+export default {
+  async fetch(request: Request): Promise<Response> {
+    console.log(accountId) // Logs "<EXAMPLE-ACCOUNT-ID>"
+    return new Response("Hello, world!")
+  },
+};
+```
+
+</TypeScriptExample>
+
+This approach is useful for initializing configuration or accessing environment variables from deeply nested functions without passing `env` through every function call. For more details, refer to [Importing `env` as a global](/workers/runtime-apis/bindings/#importing-env-as-a-global).
+
 ## Cron Triggers
 
 To handle a [Cron Trigger](/workers/configuration/cron-triggers/) event in a Worker written with ES modules syntax, implement a [`scheduled()` event handler](/workers/runtime-apis/handlers/scheduled/#syntax), which is the equivalent of listening for a `scheduled` event in Service Worker syntax.

src/content/docs/workers/runtime-apis/handlers/fetch.mdx

@@ -34,7 +34,7 @@ The Workers runtime does not support `XMLHttpRequest` (XHR). Learn the differenc
 
 * `env` object
 
-  * The [bindings](/workers/configuration/environment-variables/) available to the Worker. As long as the [environment](/workers/wrangler/environments/) has not changed, the same object (equal by identity) may be passed to multiple requests.
+  * The [bindings](/workers/runtime-apis/bindings/) available to the Worker. As long as the [environment](/workers/wrangler/environments/) has not changed, the same object (equal by identity) may be passed to multiple requests. You can also [import `env` from `cloudflare:workers`](/workers/runtime-apis/bindings/#importing-env-as-a-global) to access bindings from anywhere in your code.
 
 * <code>ctx.waitUntil(promisePromise)</code> : void
 

src/content/docs/workers/runtime-apis/nodejs/process.mdx

@@ -20,21 +20,14 @@ Workers-specific implementation details apply when adapting Node.js process supp
 
 In the Node.js implementation of `process.env`, the `env` object is a copy of the environment variables at the time the process was started. In the Workers implementation, there is no process-level environment, so by default `env` is an empty object. You can still set and get values from `env`, and those will be globally persistent for all Workers running in the same isolate and context (for example, the same Workers entry point).
 
-When [Node.js compatibility](/workers/runtime-apis/nodejs/) is turned on and the [`nodejs_compat_populate_process_env`](/workers/configuration/compatibility-flags/#enable-auto-populating-processenv) compatibility flag is set, `process.env` will contain any [environment variables](/workers/configuration/environment-variables/),
+When [Node.js compatibility](/workers/runtime-apis/nodejs/) is enabled and the [`nodejs_compat_populate_process_env`](/workers/configuration/compatibility-flags/#enable-auto-populating-processenv) compatibility flag is set (enabled by default for compatibility dates on or after 2025-04-01), `process.env` will contain any [environment variables](/workers/configuration/environment-variables/),
 [secrets](/workers/configuration/secrets/), or [version metadata](/workers/runtime-apis/bindings/version-metadata/) metadata that has been configured on your Worker.
 
-### Relationship to per-request `env` argument in `fetch()` handlers
-
-Workers have a concept of [environment variables](/workers/configuration/environment-variables/) that are applied on a per-Worker and per-request basis.
+Setting any value on `process.env` will coerce that value into a string.
 
-By default, these are not accessible via the `process.env` API.
-To automatically populate environment variables and secrets on `process.env`, enable
-the [`nodejs_compat_populate_process_env`](/workers/configuration/compatibility-flags/#nodejs_compat_populate_process_env)
-compatibility flag and disable the `disallow_importable_env` compatibility flag.
-It is also possible to manually copy these values into `process.env` if
-necessary -- but only within the context of a request.
+### Alternative: Import `env` from `cloudflare:workers`
 
-Setting any value on `process.env` will coerce that value into a string.
+Instead of using `process.env`, you can [import `env` from `cloudflare:workers`](/workers/runtime-apis/bindings/#importing-env-as-a-global) to access environment variables and all other bindings from anywhere in your code.
 
 ```js
 import * as process from "node:process";