JonnyBurger
commented
3 months ago I would like it to be configurable
Trying to use Bun as a Rollup replacement for creating ESM versions of browser modules They can be used in development and production, and will be bundled again by Webpack, which also does inlining of process.env.NODE_ENV
So I would like it to preserve process.env.NODE_ENV so that Webpack can later decide what to do with it
What is the problem this feature would solve?
In testing our Bun-based lambda while prepping its rollout to production, I realized that despite the documentation saying that environment variable inlining occurs when building, the bundler actually doesn't. This resulted in my PR to remove from the documentation any mention of environment variable inlining until the feature is added back somehow. Being able to choose whether or not this is done would be really helpful and would be a nice way to accomplish the feature without forcing anyone into behavior they don't want.
For frontend apps, having environment variables inlined is helpful. However, in the case of server-side apps on Node.js or Bun, being able to read environment variables at runtime is helpful. This is especially so on serverless platforms with shared execution environments where secret values are best accessed via environment variables.
What is the feature you are proposing to solve the problem?
A configuration flag for the bundler to enable/disable environment variable inlining. For example:
Perhaps
target: 'browser'could inline by default andtarget: 'bun'andtarget: 'node'could disable inlining, although inconsistent/unexpected behavior between targets will probably confuse more than help; just mentioning this for completeness in case I'm not thinking of a better option.What alternatives have you considered?
Manual value replacement with a text replacement engine like
sed