Netlify adapter: Optional chaining "?." not supported by default in netlify

[jsilveira]

Describe the bug

After successfully deploying a very simple Svelte Kit app (one page, one json endpoint) with netlify adapter, my deploys would succeed but when visiting the deployed production website netlify would fail with error:

Runtime.UserCodeSyntaxError: SyntaxError: Unexpected token '.'
    at _loadUserApp (/var/runtime/UserFunction.js:98:13) (...)

Not being able to debug netlify, it took me quite some time of googling to realize this was caused by the optional chaining operator ?. being used in my code and not being supported by the default Netlify build (and not being transpiled during build).

I worked around the issue by adding extra configuration to vite so that the js code was lowered to es6:

vite: {
            build: {
              target: [ 'es6' ]
            },
         ...

I took the default demo svelte kit app, added ?., followed https://github.com/sveltejs/kit/tree/master/packages/adapter-netlify steps and deployed and reproduced the error. If others are experiencing this onboarding to svelte kit and netlify adapter It would be important to change the adapter to handle this by default more gracefully or improve documentation? Am I missing something obvious here?

Reproduction

Repo reproducing this: https://github.com/jsilveira/bug-sveltekit-optional-chaining-netlify (svelte kit default app modifying src/routes/todos/index.json.js:8 to use ?.). Deployed in netlify, visit: https://distracted-wozniak-9548a1.netlify.app/todos to see the netlify error in action.

System Info

Binaries:
    Node: 14.15.3
    npm: 6.14.9
  npmPackages:
    @sveltejs/adapter-netlify: 1.0.0-next.33 => 1.0.0-next.33
    @sveltejs/kit: next => 1.0.0-next.188
    svelte: ^3.44 => 3.44.0

Severity

serious, but I can work around it

[jsilveira]

A small update: it seems another way to prevent this issue is adding the following to netlify.toml:

[functions]
  node_bundler = "esbuild"

[Conduitry]

This sounds like the same as - or very similar to - #2679.

[pngwn]

This is similar but slightly different to the CF Worker issue. This is an AWS Lambda runtime error, whereas the CF worker issue is a bundler error as far as I can tell.

Netlify functions written in JavaScript are not bundled by default and the default AWS Lambda runtime is node 12 which does not support optional chaining. Typescript projects are automatically bundled with esbuild which you can force for JS functions via the above configuration.

An alternative (or addition) to bundling with esbuild is to set an more appropriate AWS Lambda runtime. You can set the AWS_LAMBDA_JS_RUNTIME environment variable to nodejs14.x

Something like the following should work.

[build]
# your config

[build.environment]
  AWS_LAMBDA_JS_RUNTIME = "nodejs14.x"

[jsilveira]

Thanks @pngwn, I can confirm that activating node_bundler = "esbuild" works, so I wonder if this is something that the netlify adapter should do by default? To be honest, the only reason I created this issue is that I think this is something that I would expect to work right out of the box, without having to investigate in github issues for a solution. As far as I can tell the setup to reproduce this issue is pretty normal!

[benmccann]

node_bundler = "esbuild" works, so I wonder if this is something that the netlify adapter should do by default?

I don't like the idea of introducing a second unnecessary bundling step

I think setting AWS_LAMBDA_JS_RUNTIME = "nodejs14.x" is a much better solution since Kit doesn't support Node 12 and there may be other things that would break if you only relied on transpiling

[jsilveira]

Maybe it makes sense, but in that case, I would put that information front and center in the docs, as the consequences of not doing so and discovering this problem when deploying are really ugly. Especially when node 12 is a relic for today's standards!

[accuser]

Had this same issue, and like @jsilveira it took me a while to work out what was going on as the error message is quite opaque (this is a Netlify issue). Setting AWS_LAMBDA_JS_RUNTIME = "nodejs14.x" worked, and I agree with @benmccann that this is the correct resolution. It would be good to document this with the Netlify adapter, since this really needs to be front-and-centre.

[bluwy]

Feel free to send a PR to update the docs!

[benmccann]

Per a comment on the PR (#2715 (comment)) from the Netlify team:

The good news is that we will very shortly be switching the default Lambda runtime to 14, and this issue has moved that up the priority list.

The current correct solution is to set AWS_LAMBDA_JS_RUNTIME in the site UI, not in the toml.

[swyxio]

just ran into this issue today on netlify. https://app.netlify.com/sites/swyxkit/deploys/61cdec4d0b7920ae2185032e

1:29:28 AM: $ npm run build
1:29:28 AM: > swyxkit@0.0.1 build /opt/build/repo
1:29:28 AM: > svelte-kit build
1:29:28 AM: (node:3291) ExperimentalWarning: The ESM module loader is experimental.
1:29:28 AM: file:///opt/build/repo/node_modules/@sveltejs/kit/dist/cli.js:926
1:29:28 AM: 			https = https || !!vite_config.server?.https;
1:29:28 AM: 			                                      ^
1:29:28 AM: SyntaxError: Unexpected token '.'
1:29:28 AM:     at Loader.moduleStrategy (internal/modules/esm/translators.js:81:18)
1:29:28 AM: npm ERR! code ELIFECYCLE
1:29:28 AM: npm ERR! errno 1
1:29:28 AM: npm ERR! swyxkit@0.0.1 build: `svelte-kit build`

just leaving here for others to find - gonna try the solution mentioned in #2715 (comment) (set env var in UI because env var in toml doesnt work)

[dimavolo]

I tried both solutions:

node_bundler = "esbuild" didn't work in netlify.toml and neither did setting in the Netlify Dashboard UI an environment variable for AWS_LAMBDA_JS_RUNTIME = "nodejs14.x".

I tried setting in netlify.toml:

[build.environment]
   AWS_LAMBDA_JS_RUNTIME = "nodejs14.x"

I did a "clear cache and deploy". Same problem:

{"errorType":"Runtime.UserCodeSyntaxError","errorMessage":"SyntaxError: Unexpected token '.'","trace":["Runtime.UserCodeSyntaxError: SyntaxError: Unexpected token '.'"," at _loadUserApp (/var/runtime/UserFunction.js:200:13)"," at Object.module.exports.load (/var/runtime/UserFunction.js:242:17)"," at Object.<anonymous> (/var/runtime/index.js:43:30)"," at Module._compile (internal/modules/cjs/loader.js:1085:14)"," at Object.Module._extensions..js (internal/modules/cjs/loader.js:1114:10)"," at Module.load (internal/modules/cjs/loader.js:950:32)"," at Function.Module._load (internal/modules/cjs/loader.js:790:12)"," at Function.executeUserEntryPoint [as runMain] (internal/modules/run_main.js:76:12)"," at internal/main/run_main_module.js:17:47"]}

[goynang]

@dimavolo I was getting the exact same error your were getting. My previously working site suddenly spewed out that error after updating to latest kit and netlify-adapter. I could recreate it locally using netlify dev as well.

I was able to resolve it by adding...

[functions]
  node_bundler = "esbuild"

...to my netlify.toml config file as mentioned above. Did you add it in the right place (i.e. for functions, not for the build settings)? I also cleared out all build directories/caches to ensure I was getting the new version and I already had my ENV setting (via Netlify UI) stating the node version.

It looks to me that there is a bug in the CJS version of adapter-netlify which causes a bad code substitution during building which results in some errant code being generated. When using CJS, line 6 of .netlify/handler.js becomes...

var ./server/app.js = require('./server/app.js');

...which contains the syntax error that leads to the problem we both encountered. The CJS version of handler.js (before code generation) looks like

var APP = require('APP');

...whereas the ESM version looks like...

import { App } from 'APP';

The code substitution is based on replacing APP with ./server/app.js so looks like maybe just a simple case problem (APP vs App).

[benmccann]

From https://docs.netlify.com/functions/build-with-javascript/?#runtime-settings:

For all JavaScript functions deployed on or after December 13, 2021, Netlify uses Node.js 14 as the default runtime.

This should be fixed now