-
Notifications
You must be signed in to change notification settings - Fork 160
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
ESM support stopped working in Cloud Functions (GCF) #407
Comments
I'm also seeing this but noticed that switching back to Node 14 deploys successfully... |
Same here.. ESM support is not working with Node.js 16 runtime.. Any update from Google? |
Sorry to hear you are having trouble with this feature. I just tried this out for myself and I wasn't able to repro the issue. Could you please share more information about your project structure? |
I see what is going on. The failure happens when building an ESM function with our GCP Buildpacks. We run node --check foo.mjs
(node:2290922) Warning: To load an ES module, set "type": "module" in the package.json or use the .mjs extension.
(Use `node --trace-warnings ...` to show where the warning was created)
/usr/local/google/home/mattrobertson/gcf/functions-framework-nodejs/test/data/esm_mjs/foo.mjs:12
export {testFunction};
^^^^^^
SyntaxError: Unexpected token 'export'
at Object.compileFunction (node:vm:352:18)
at wrapSafe (node:internal/modules/cjs/loader:1031:15)
at checkSyntax (node:internal/main/check_syntax:66:3)
at node:internal/main/check_syntax:39:3 |
This appears to be a regression in v16 of the Node.js engine. I have filed nodejs/node#41189. Unfortunately, the work around is to use |
Thanks for the update Matthew. |
Well there went a few hours of tinkering with my package.json; so the fix is basically just wait for a node update? Or is is this something GCP is working on? In the meantime node 14 it is! |
@matthewrobertson Is it possible to revert the version of node v16 used in the GCF runtime? |
That seems like best stopgap given that the update was so recent |
Actually even better solution would be to allow buildpacks take in and preserve NODE_OPTIONS from environment, that way ones who need it can pass NODE_OPTIONS=--experimental-modules which helps currently used node --check to understand and allow modules. This is both feature request (to allow custom NODE_OPTIONS build) and solution to this issue which is not blocked by nodejs release, testing etc times. |
@webervin Maybe open a new issue referencing this comment and this issue? (the ... button on the top right of your comment) |
I think the easiest fix here is to just skip the |
@webervin it is already possible to set build time environment variables when deploying functions, but I am not sure setting |
A fix was pushed in node about 9 days ago, it's just a waiting game for node to release the change. nodejs/node#41189 , nodejs/node#41198 , and nodejs/node@3f7dabd |
@matthewrobertson is there an ETA on when this will be fixed? |
I was really hoping that Node.js would have released a fix for this by now, but I just tested with |
side note: it does seem to be fixed in nodejs |
The needed commit is already scheduled for backporting as indicated by the lts-watch label in nodejs/node#41198. We'll have to wait until the 16 LTS backporter is ready to backport and cut a new release... |
I'd say go for a temporary workaround until whenever Node gets around to a new release of 16 (anyone know when that might be?) |
Is there any plans on resolving this soon? I'm using another package that requires Node 16 so going back to node 14 engine is not an option for me. |
Understood. Matt is actively working on a solution that is visible internally #407 (comment). There's no update since yesterday. |
This is a temporary workaround for a regression in Node.js 16 that causes `node --check` to return false positives when a project is using ESM. More information here: GoogleCloudPlatform/functions-framework-nodejs#407 PiperOrigin-RevId: 423439009 Change-Id: I26ad943e8fb55e868ece996bd5d2f7470afbec5a
When can we expect these changes to be deployed to prod? |
The work around is rolling out now. It should be in all GCP regions by the end of the week. |
Just to be clear: this will not be needing a rollback to node 14, right? |
@matthewrobertson has the fix landed in all GCP regions yet? I am still seeing this issue in the |
Yeah same in europe-west3 |
The rollout completed a few hours ago. I just confirmed that I can deploy an ESM function in |
Might be not related to this particular update, but coincidently Yarn-based cloud functions stopped working:
|
ESM support stopped working today in Google Cloud Functions (GCF) environment with Node.js 16 runtime. Trying to deploy an ESM codebase fails with the error:
package.json
index.js
$ cloud functions deploy esm \ --project=example --region=us-central1 --allow-unauthenticated --trigger-http \ --entry-point=esm --memory=256MB --runtime=nodejs16 --source=. \ --set-env-vars="NODE_OPTIONS=--loader=./.pnp.loader.mjs --require=./.pnp.cjs --no-warnings"
Workaround (if you want to preserve ESM in your project)
@babel-preset/env
,target: { node: "14" }
presetapi/rollup.config.js
Ref #233, #292, nodejs/node#41189, nodejs/node#41198
The text was updated successfully, but these errors were encountered: