Unified access to environment variables?

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?

@KGZM

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().

@yusukebe

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

@thecotne

@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.

@yusukebe

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

@Manouchehri

@Manouchehri

Does this not work?

import { env } from 'hono/adapter'

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

Navigation Menu

Repository navigation

Unified access to environment variables? #140

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Unified access to environment variables? #140

Description

Activity

yusukebe commented on Feb 8, 2024

thecotne commented on May 23, 2024

yusukebe commented on Jun 3, 2024

Manouchehri commented on Jan 28, 2025

yusukebe commented on Jan 29, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions