Unified access to environment variables?

[KGZM]

If c.env is intended to be for uniform environment access then we need some way to provide values to c.env when using the node-server.

I read issue #72, but the discussion there seems to miss the point. The problem isn't reading the environment, it's providing it.

Take a look at this search for c.env on the middleware repo.

The decision tree "If on cloudflare workers use c.env, else if on NodeJS use process.env" doesn't seem to work with shared middleware.

How is shared middleware supposed to work if c.env and process.env remain entirely separate?

[yusukebe]

Hi @KGZM

We should use env() in hono/adapter.

import { env } from 'hono/adapter'

That, the code in the search results is not good. Many of these were created when there was no hono/adapter yet, and also assumed Cloudflare Workers. We should have used env().

[thecotne]

@yusukebe should c.env be deprecated and all first party packages migrated to use hono/adapter ?

[yusukebe]

@thecotne

@yusukebe should c.env be deprecated and all first party packages migrated to use hono/adapter ?

No. We have to recommend using c.env for the Cloudflare Workers/Pages. It is now very familiar to the user. We don't need to stop using it.

[Manouchehri]

@yusukebe How do I use import { env } from 'hono/adapter' when I am using OpenAPIHono?

[yusukebe]

@Manouchehri

Does this not work?

import { env } from 'hono/adapter'

app.openapi(route, (c) => {
  console.log(env(c)) // <===
  // ...
})