-
Notifications
You must be signed in to change notification settings - Fork 916
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
Inline process.env variable references directly when installing. #1044
Conversation
This pull request is being automatically deployed with Vercel (learn more). 🔍 Inspect: https://vercel.com/pikapkg/snowpack/98kpdj1su |
d011c8d
to
bfff9ca
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1 on this approach, left some comments
snowpack/src/commands/install.ts
Outdated
rollup: userDefinedRollup, | ||
treeshake: isTreeshake, | ||
polyfillNode, | ||
}, | ||
} = config; | ||
|
||
const env = { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So we actually have some great code here that you could bring back from older version of Snowpack, where this was the main way that we did process.env replacement. For example, I'd love to see this function brought back (but with everything besides env removed: https://github.com/pikapkg/snowpack/blob/v2.6/src/commands/install.ts#L127
That way, your plugin usage is simplified to:
rollupPluginReplace(getRollupReplaceKeys(userEnv)),
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think we want to quite do that. getRollupReplaceKeys
conflates computing the env
dictionary and stringifying it for replacement. In my approach, I compute env
first so that both the replacement and the process polyfill can use it, guaranteeing that they'll have the same process.env
values.
However, my code is almost exactly the same -- it's just split into two parts. I changed it to use JSON.stringify
instead, and I can break out the two reduce
s into functions if you'd like but I think they're so small it won't really improve readability much.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay, that makes sense. The install()
function is large enough as it is, so In that case it would still be great to move this specific chunk of logic into a separate const env = generateEnvObject(userEnv)
function.
(the second reduce below is fine to keep inline)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No problem, extracted. But I work from email so I didn't see your edit about keeping the second reduce inline and extracted it as well -- hope it's OK. 😊
@@ -4631,6 +4631,11 @@ exports[`snowpack build package-tippy-js: web_modules/import-map.json 1`] = ` | |||
|
|||
exports[`snowpack build package-tippy-js: web_modules/tippyjs.js 1`] = ` | |||
"import { c as createPopper } from './common/popper-XXXXXXXX.js'; | |||
/**! | |||
* tippy.js v6.2.6 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
huh, this is unexpected. Not necessarily bad, just suprising
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I wasn't too sure what to make of it either. My only guess is that something (?) now knows statically that we're not making a production build, so it's keeping the comment there.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
perfect timing too, I think this may be related to #1026 (reply in thread) Update: yup, I can confirm that this fixes #1026 for me 🎊 |
Changes
Inline process.env property references directly when installing, as discussed in #1000.
Testing
Existing tests seem to provide sufficient coverage for this change.
I assume the react-related changes in the snapshots are due to modules getting tree-shaken away thanks to inlining
NODE_ENV
.This change is