-
-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
process.browser etc #8
Comments
|
Should |
In Snowpack, we're trying to be very careful not to extend If you check https://www.snowpack.dev/#environment-variables, you'll see we already have support for Ideas (any of which I'd be happy with):
|
I noticed in the Snowpack 2.15 changelog that it's now I couldn't fully test it because as soon as you add |
Just tested this with Snowpack 2.15.1, and it works: <h1>Hello {import.meta.env.SSR ? 'server' : 'client'}!</h1> |
Will all environment variables get put in |
@benmccann yes and it's my biggest concern with snowpack currently. And since we're doing server and browser during snowpack, we really really cannot put server-side secrets anywhere within Snowpack's reach. Or at least make sure that it's shaken away during the 2nd optimization pass. |
@lukeed that's incorrect, we protect for this by only supporting Next.js, Create React App, etc. all have similar ideas of only allowing "special prefixed" env variables to be added to the project for this exact reason. For ex, Next.js uses It looks like Next.js supports all process.env secrets in SSR mode but that then get removed in the frontend build. I'd be +1 for adding a similar workflow to Snowpack. |
You're right that in a browser-only development space, this is easy to manage, to be aware of, and to workaround. It's generally not a problem. The prefix is the extra, much-needed callout that says "hey, this is public~!" But when juggling a dual-environment setup, which is what we're talking about, it doesn't fit in the same nice box. In a SSR context, all this really means is that a user goes from using Quick example – on server-side preload, you interface directly with a |
Just to make sure I'm following, do you have the same concerns with how Next.js currently does this? https://nextjs.org/docs/basic-features/environment-variables (all secrets available in SSR mode, all non-PUBLIC secrets removed from the frontend build). |
No, because they're directly in control of the build pipelines and can guarantee that the server-side secrets are removed/kept separate from the client build. But Next.js is not comparable to Snowpack. Snowpack will write the secrets into the output files (which is fine), but it requires a sufficiently aware user and/or a Next.js-like framework (eg, svelte kit) to take responsibility for ensuring that happens correctly. |
In Next, Rollup/webpack/whatever is writing secrets into output files too. It's fine – just something or someone has to make sure they're juggling and/or cleaning that up correctly. My "concern" with Snowpack is only that it will eventually be approached by non-SvelteKit developers, who won't be aware enough of this "gotcha" (too strong of a word), and so when they go to roll their own solution, they'll leak server-only ENVs everywhere by mistake. |
I think that's a misunderstanding of how SSR works in Snowpack (at least as of 2.15). Snowpack now has an idea of true SSR mode (which svelte/kit uses internally) so that if we wanted to we actually can control / guarantee the server-side secrets are removed/kept separate from the client build while still making them available in SSR mode.
|
Ah cool, glad to hear! I'll check it out again. Ran into that problem time & time again when setting up the custom Skypack rig. |
The Sapper template allows you to write
process.browser
to determine if you're in the browser or in Node. Not sure how to do that here. Snowpack hasimport.meta.env
which feels like the way you're supposed to go, though I'm not sure how to differentiate between SSR and not. Perhaps theisSSR
boolean that gets passed around could also be used to populateimport.meta.env.SSR
?The text was updated successfully, but these errors were encountered: