You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hello! We build Node.js application that runs as Lambda@Edge function in AWS. Unfortunatelly edge functions doesn't support process.env variables in the runtime (yes, it has solution, but it's far from perfect).
So we would like to inline env variables to Node.js app during build. Based on documentation I hoped that package.json config forces @parcel/transformer-js to inline vars.
But based on my investigation there is currently no way to force inlining process.env variables into the bundle. Variables are replaced for non-Node.js environment. So basically setting target.context = "browser" does the trick (similar answer here) but I don't think this is proper way to solve the thing.
Wouldn't be reasonable to make this feature configurable? (with default behavior based on target env) Of course somebody could develop another transformer specially for this purpose but as I see @parcel/transformer-js works pretty fast as the core is written in Rust.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Hello! We build Node.js application that runs as Lambda@Edge function in AWS. Unfortunatelly edge functions doesn't support process.env variables in the runtime (yes, it has solution, but it's far from perfect).
So we would like to inline env variables to Node.js app during build. Based on documentation I hoped that
package.json
config forces@parcel/transformer-js
to inline vars.But based on my investigation there is currently no way to force inlining
process.env
variables into the bundle. Variables are replaced for non-Node.js environment. So basically settingtarget.context = "browser"
does the trick (similar answer here) but I don't think this is proper way to solve the thing.Wouldn't be reasonable to make this feature configurable? (with default behavior based on target env) Of course somebody could develop another transformer specially for this purpose but as I see
@parcel/transformer-js
works pretty fast as the core is written in Rust.Beta Was this translation helpful? Give feedback.
All reactions