stevejhiggs / aws-lambda-typescript Goto Github PK

The name mangling will result in the lambda handler function, as specified in 'lambda-config.js', not being found when attempting to run the lambda.

It looks like all the UglifyJS config is applied from 'node_modules/gulp-webpack-typescript-pipeline/webpack.config.release.js', leaving no control for the developer to modify or override settings.

Have you encountered this problem and how do I overcome it?

It's getting increasingly hard to stick with Gulp 3.

Can you publish a build of gulp-webpack-typescript-pipeline with the Gulp 4 support and then update aws-lambda-typescript to use it?

I am not able to run either gulp lambda:run/package. It fails with the following error:

gulp lambda:package

SyntaxError: Unexpected token ] in JSON at position 262
at Object.parse (native)
at parse (/Users/omatrot/Projects/code/lambda/node_modules/tsconfig/src/tsconfig.ts:195:15)
at readFileSync (/Users/omatrot/Projects/code/lambda/node_modules/tsconfig/src/tsconfig.ts:181:10)
at Object.loadSync (/Users/omatrot/Projects/code/lambda/node_modules/tsconfig/src/tsconfig.ts:151:18)
at readConfig (/Users/omatrot/Projects/code/lambda/node_modules/ts-node/src/index.ts:425:18)
at Object.register (/Users/omatrot/Projects/code/lambda/node_modules/ts-node/src/index.ts:189:18)
at Object. (/Users/omatrot/Projects/code/lambda/node_modules/aws-lambda-typescript/localServer.js:1:20)
at Module._compile (module.js:570:32)
at Object.Module._extensions..js (module.js:579:10)
at Module.load (module.js:487:32)

can't figure out what JSON this is about.

It seems like AWS Lambda has changed their deployment mechanism... "gulp lambda:deploy" now gives me errors like:

[11:14:21] 'lambda:upload' errored after 668 ms
[11:14:21] ResourceConflictException: The operation cannot be performed at this time.
An update is in progress for resource: arn:aws:lambda:us-east-1:###:function:ABC
...
[11:14:21] 'lambda:deploy' errored after 16 s

However, the function is successfully updated after 30 seconds or so. I feel like I saw a notice that Lambda deployment changed to be asynchronous or something, but I can't find a specific reference just now.

Can aws-lambda-typescript be updated to use whatever the new sequence of calls is so it doesn't generate the upload error, and also doesn't finish running until the function has been successfully updated?

P.S. Node 14, Apple M1, aws-lambda-typescript 5.1.1. I'll try updating my aws cli to see if that helps. (And... it didn't help.)

Hi,

I followed the steps in the help and got:

...\node_modules\aws-lambda-typescript\localServer.js:6
  app.post('/', async (req, res) => {
                      ^
SyntaxError: Unexpected token (
    at createScript (vm.js:56:10)
    at Object.runInThisContext (vm.js:97:10)
    at Module._compile (module.js:542:28)
    at Object.Module._extensions..js (module.js:579:10)
    at Module.load (module.js:487:32)
    at tryModuleLoad (module.js:446:12)
    at Function.Module._load (module.js:438:3)
    at Module.require (module.js:497:17)
    at require (internal/module.js:20:19)
    at Object.<anonymous> (...\node_modules\aws-lambda-typescript\index.js:10:21)

Help will be appreciated.
Thanks,
Yishay

If you run "gulp lambda:deploy" and the Typescript code has an error, it does not stop, but instead deploys something that just doesn't work (e.g., causes 502 gateway errors when invoked through API Gateway).

My latest was: [tsl] ERROR in blah/blah/blah.ts(778,17)
TS1005: ',' expected.

I would much rather that if the Typescript code has an error, the whole process stops and nothing gets deployed to AWS. Can an error in the build stage cause the deploy to abort?

(I know I could run the build step separately, but I'm not willing to wait for THREE NPM install runs in the usual case where everything works...)

Due to registerBuildGulpTasks... around line 57 it bombs out if the pathToLambda doesn't exist... but of course if you're performing a lambda:init then index.ts doesn't exist yet so the lambda:init operation just fails.

Hello there,

I'm just starting to develop aws lambda functions locally with node (TypeScript) and I found this repo very interesting; congratulations for this great tool! Unfortunately, I am unable to configure Visual Studio Code for debugging.

Currently you already mention that it is mandatory to set protocol attribute to "inspector", but it would be very helpful if you could include in the documentation an example of the debug configuration for VSCode.

Thank you,
Regards.

So I've now tried a Lambda with RDS (MySQL).

If Webpack (or uglify or whatever is under the covers) gets its hands on the Node MySQL driver, it throws a protocol error and fails when you try to connect.

I can exclude MySQL from the Webpack build by adding it to 'externals' list in tsOptions in index.js here. But then I need to manually create the zip with the Webpack-output index.js and also a node-modules directory I construct with the subset of packages that mysql needs. (And then it works fine, no protocol error.)

You once mentioned perhaps ditching Webpack, which I assume would solve this. But I'm also open to any other solution -- is there some better way to say I want mysql and its dependencies (of which there are perhaps 7) excluded from the mangling but included as node_modules in the ZIP?

Worst case, if I could provide my own list of externals to registerBuildGulpTasks that would help because I wouldn't have to edit the externals list in the code for this lib in the node_modules of every MySQL-using lambda. And I could just put my own script in place to call lambda:build, make the modified ZIP, and then call lambda:upload.

I have a JavaScript lambda where I make a single Cognito call to check whether the aws-sdk is working:

let Cognito = require('aws-sdk/clients/cognitoidentityserviceprovider');

exports.handler = (event, context, callback) => {
    let client = new Cognito({ apiVersion: '2016-04-19', region: 'us-east-1' });

    let params = {
        AuthFlow: 'REFRESH_TOKEN_AUTH',
        ClientId: 'MY_CLIENT_ID',
        UserPoolId: 'us-east-1_MY_POOL_ID',
        AuthParameters: {
            REFRESH_TOKEN: 'some bogus value'
        }
    };
    client.adminInitiateAuth(params, function(err, result) {
        console.log(err);
        console.log(result);
        // Test complete.  Now go on and do the regular processing
    });

I expect to get an error there along the lines of "invalid token" because I'm not using a real refresh token. I just want to log the output of the call and then go on to do the regular processing for the Lambda. Here's what I get in the log (as expected):

NotAuthorizedException: Invalid Refresh Token
at Request.extractError (/var/task/node_modules/aws-sdk/lib/protocol/json.js:48:27)

Here's my TypeScript version:

import {Callback, Handler} from 'aws-lambda';
import * as CognitoIdentityServiceProvider from "aws-sdk/clients/cognitoidentityserviceprovider";

const func: Handler = (event, context, callback: Callback) => {
  let client = new CognitoIdentityServiceProvider({ apiVersion: '2016-04-19', region: 'us-east-1' });

  let params = {
    AuthFlow: 'REFRESH_TOKEN_AUTH',
    ClientId: 'MY_CLIENT_ID',
    UserPoolId: 'us-east-1_MY_POOL_ID',
    AuthParameters: {
        REFRESH_TOKEN: 'some bogus value'
    }
  };
  client.adminInitiateAuth(params, function(err, result) {
    console.log(err);
    console.log(result);
    // Test complete.  Now go on and do the regular processing
  });

I expected the same result. However, when I make the same call in the TypeScript version of the Lambda, I get this:

{ CredentialsError: Missing credentials in config
    at r (/var/task/index.js:1:143946)
    at constructor.getCredentials (/var/task/index.js:1:144474)
    ...

In other words, it fails to recognize that the current user/identity/whatever can even call Cognito. The two Lambdas use the same execution role -- so I'm pretty sure it's not actually a permissions problem, but that somehow the aws-sdk isn't working properly.

I saw one documentation page saying you must set up a JSON loader in your Webpack config for the aws-sdk to work (and another saying this is now automatic), and another saying you had to somehow exclude the aws-sdk in your configuration, but these were somewhat out of date. I'm not yet sure what the real issue is.

This is not so much a problem, as a "gotcha" that others might want to be aware of...

Don't do this:

import {DocumentClient} from "aws-sdk/lib/dynamodb/document_client";
...
const client = new DocumentClient();

Do this instead:

import {DynamoDB} from "aws-sdk";
...
const client = new DynamoDB.DocumentClient();

Otherwise you get a bizarre error in loading modules (Cannot set property 'Converter' of undefined in module.js called from /var/runtime/node_modules/aws-sdk/lib/dynamodb/translator.js)

When I try to import modules, I get this error. I have confirmed that the package.json has the required modules and there is a node_modules directory with the required module. Any suggestions on what else I should be looking for?

I've never used webpack before (just gulp-typescript).

I've installed arangojs but I'm still getting a runtime error:

Cannot find module 'arangojs'

Apparently Webpack strips out process.env calls by default (or substitutes dev-time values or something), which means that a Lambda attempting to use environment variables defined in the Lambda console just gets nothing (or the wrong value).

To fix this, the webpack config in gulp-webpack-typescript-pipeline needs this:

var webpack = require('webpack');
...
plugins: [
      new webpack.DefinePlugin({
        'process.env': 'process.env'
      })
    ]

That results in the process.env calls being passed through to the final processed code.

I guess again, that can be some kind of option that aws-lambda-typescript sets... I'm not sure whether you'd rather it be something like "preserveEnvironmentCalls" or have it accept a list of plugins or what.

First time trying aws-lambda-typescript on a project pulling dependencies from a custom NPM repository. The settings for it are in .npmrc in the project directory. Unfortunately during a gulp lambda:deploy, the package.json is copied but .npmrc is not, so the final build fails due to missing dependencies.

Can .npmrc be copied along with the other config files (if it is present in the project dir)?

Way back on v3, I would use e.g. // tslint:disable-line and things like that.

I just updated to v4 and those notations seem to be ignored now. How do you now suppress a typescript error that you know is not a breaking problem (e.g. let vs const) for a particular block of code? The tslint docs I see still seem to indicate that should work, so does the current build process use something other than tslint or force it to ignore inline annotations?

When I build with "gulp lambda:package" and upload the generated ZIP file as my Lambda function, I get this error in the Lambda console:

"errorMessage": "Handler 'handler' missing on module 'index'"

I tried renaming "func" to "handler" but that didn't do it.

I also tried changing my lambda config from "index.handler" to "index.default" but then I just get:

"errorMessage": "Handler 'default' missing on module 'index'"

Any suggestions?