ES6 import syntax

[jwalkerphonesoap]

Use case description

Since Lamda now supports node 14.x (https://aws.amazon.com/blogs/compute/node-js-14-x-runtime-now-available-in-aws-lambda/), it would be nice to be able to write node services using ES6 import syntax without a transpiler.

[pgrzesik]

Hello @jwalkerphonesoap - thanks for the proposal. Could you be more specific as to what do you expect from the Serverless Framework in terms of supporting that?

[garethmcc]

This is an issue when adding org and app as the wrapping mechanism for monitoring uses requires and this conflicts with the package.json setting import as the option to use.

[pgrzesik]

Thank you @garethmcc for clarification on that. I think we should move this issue to the enterprise-plugin repository and figure out a way to address it.

[pgrzesik]

Hello @jwalkerphonesoap - I did some extra digging and it seems like at the moment it's impossible to use ES modules in AWS Lambda, event with Node 14 - in a simple example with handler as below, that's the error I'm getting:

'use strict'

export hello = async (event) => {
  return {
    statusCode: 200,
    body: JSON.stringify(
      {
        message: 'Go Serverless v1.0! Your function executed successfully!',
        input: event,
      },
      null,
      2
    ),
  };
};

{
  "errorType": "Error",
  "errorMessage": "Must use import to load ES Module: /var/task/handler.js\nrequire() of ES modules is not supported.\nrequire() of /var/task/handler.js from /var/runtime/UserFunction.js is an ES module file as it is a .js file whose nearest parent package.json contains \"type\": \"module\" which defines all .js files in that package scope as ES modules.\nInstead rename handler.js to end in .cjs, change the requiring code to use import(), or remove \"type\": \"module\" from /var/task/package.json.\n",
  "trace": [
    "Error [ERR_REQUIRE_ESM]: Must use import to load ES Module: /var/task/handler.js",
    "require() of ES modules is not supported.",
    "require() of /var/task/handler.js from /var/runtime/UserFunction.js is an ES module file as it is a .js file whose nearest parent package.json contains \"type\": \"module\" which defines all .js files in that package scope as ES modules.",
    "Instead rename handler.js to end in .cjs, change the requiring code to use import(), or remove \"type\": \"module\" from /var/task/package.json.",
    "",
    "    at Object.Module._extensions..js (internal/modules/cjs/loader.js:1080:13)",
    "    at Module.load (internal/modules/cjs/loader.js:928:32)",
    "    at Function.Module._load (internal/modules/cjs/loader.js:769:14)",
    "    at Module.require (internal/modules/cjs/loader.js:952:19)",
    "    at require (internal/modules/cjs/helpers.js:88:18)",
    "    at _tryRequire (/var/runtime/UserFunction.js:75:12)",
    "    at _loadUserApp (/var/runtime/UserFunction.js:95:12)",
    "    at Object.module.exports.load (/var/runtime/UserFunction.js:140:17)",
    "    at Object.<anonymous> (/var/runtime/index.js:43:30)",
    "    at Module._compile (internal/modules/cjs/loader.js:1063:30)"
  ]
}

There's also a related StackOverflow issue: https://stackoverflow.com/questions/66676555/nodejs-14-x-native-aws-lambda-import-export-support/66688901

[gravi2]

AWS lambda now seems to support modules. Here is a good link talking about it. It has performance benefits of using await in initialization vs in handler.

https://aws.amazon.com/blogs/compute/using-node-js-es-modules-and-top-level-await-in-aws-lambda

https://aws.amazon.com/about-aws/whats-new/2022/01/aws-lambda-es-modules-top-level-await-node-js-14/

[aldilaff]

Are there any plans to add support for modules to the dashboard plugin now that aws does support it?

[jsmithdev]

found a PR with a seemingly good attempt: #692

[akremer]

This sole issue prevents us from using top level await in our entire serverless project since the wrapper still uses require. @medikoo are there plans to address this anytime soon? There seems to be a solid PR for this already #692

[medikoo]

@jsmithdev @akremer Serverless Dashboard is scheduled to be shadowed by the Serverless Console where ESM modules are fully supported.

Best if you consider switching to the Serverless Console, and you find some important features missing, please signal that to our support, it'll help us to leverage priorities

[robin-thomas]

@medikoo Does Serverless Dashboard and Console serve the same use cases? Console looks more geared towards logs.

[medikoo]

@robin-thomas in the end, Console will offer everything that Dashboard offers, and Dashboard will be turned off.

[robin-thomas]

In the end, Console will offer everything that Dashboard offers, and Dashboard will be turned off.

@medikoo any planned ETA for this?

[medikoo]

@robin-thomas there's no specific ETA, but Console is being actively worked on and improved, while there's no traction on Dashboard

[robin-thomas]

@medikoo Does Serverless Console have providers like we have in Serverless Dashboard? If not, do we need to handle that part ourselves, assuming we migrate to Console?

[akremer]

@medikoo Same question as @robin-thomas: We tried upgrading to Console but noticed that it does not enable our team to deploy without on-machine AWS keys, unlike the functionality provided by providers in Dashboard. Could you provide an ETA for when this functionality will make it into Console?

[medikoo]

@robin-thomas @akremer I no longer work at Serverless Inc. but I'm sure @Danwakeem will have for you all the answers.