process.env in code via config file

[bkniffler]

We can inject env vars by carefully naming them SNOWPACK_PUBLIC_* since #394 was merged. But I think this does not allow for enough flexibility. NextJS allows to set env variables via next.config.js (https://nextjs.org/docs/api-reference/next.config.js/environment-variables), and I'd suggest to add a similar option to snowpack.config.js buildOptions.env / devOptions.env.

What do you think?

An example: I'm using AWS CDK to execute yarn build of my website project, which uses snowpack to build the code. Instead of changing my CDK scripts environment variables (API_URI, GRAPHQL_URI, ..) with SNOWPACK_PUBLIC prefix, I'd like to keep the names and just have my snowpack.config.js file changed:

module.exports = {
  mount: {
    public: '/',
    src: '/_dist_',
  },
  plugins: ['@snowpack/plugin-react-refresh', '@snowpack/plugin-typescript'],
  buildOptions: {
    env: {
      API_URI: process.env.API_URI
    }
  },
};

[aryzing]

Thoughts on naming convention

Snowpack helps improve development by leveraging the very best and latest of web tech standards, which is great! When it comes to naming environment variables, it seems that snowpack enforces a non-standard, albeit with the best of intentions.

Fully support the sentiment and the idea to encourage best practices. However, forcing env variables to have the name of the bundler that happened to be used at the time leaks the bundling abstraction into the code. The complications this can

• need to change env vars throughout entire codebase in order to introduce snowpack (which will hurt its adoption -- it's a great tool, wouldn't want that to happen!). Nothing that isn't more than a global search-and-replace away, but more work nonetheless.
• will be akward in the future when the bundler is changed (don't plan to anytime soon, but can serve as a detracting argument for the undecided).
• lastly, and perhpas the most important, seems like this feature contradicts snowpack's philosophy of taking advantage of the very best of modern standards and tech, by introducing convention, albeit with good intentions, which may surprise users and introduces overhead.

Why do the other apps do it?

post

Seems that both Next.js and CRA have their own reasons.

Next.js seems to be using the convention because they have to distinguish between server and client env variables, which seems isn't really an issue with snowpack. It is their attempt at mitigating security risks by relying on naming conventions, and avoiding confusion for users that routinely engage with a framework that caters to both server and client.

Would probably be safer to handle security at the ci level, as it doesn't really stop anyone from adding secrets to those env vars. Although yes, they would be much easier to catch in a PR review.

CRA seems to be using the convention as a namespace to avoid clashing with other env vars. Makes sense since there's a lot going on there that users don't really have fine-grained control over until they eject, which isn't an issue with snowpack.

Therefore, can't see an overwhelming benefit in maintaining this convention.

Improving docs around dotenv

• Dotenv recommends using only a single .env file.
• However the source code includes several .env source files and references a Ruby repo that recommends having several of them.

Worth documenting which conventions are being used as it may be misleading users to think that only .env files are supported (as those are the only ones recommended by dotenvjs) while in reality the source code includes several of them and documents an alternate style for dotenv files.

Perhaps we can get inspiration from CRA's docs for snowpack's?