NodeJS Webpack builder

[buggy]

Description:

I'm proposing to add a new nodejs webpack builder that would be triggered by the presence of a webpack.config.js file.

There are two uses I can see:

1. As a Node developer I want to use TypeScript or Babel to compile my code from a more recent version of Javascript to a version supported by AWS Lambda.
2. As a Node developer I want to use tree shaking to reduce the size of my code.

The builder could be based on the existing nodejs npm builder. It would build the code using a command like npx webpack-cli app.ts -o ../.aws-ts/build/HelloWorldFunction/app.js --config ./webpack.config.js instead of using npm pack. The package.json would probably need to be copied independently.

The Serverless Framework uses the same approach (a serverless-webpack plugin) for TypeScript support through the webpack ts-loader.

[Jeremias-Tecnom]

I like this.
I ve been using this SAM scaffold (i've adapted it to my sollutions).
What I like about it, is that it builds multiple functions wich are in separate folders.

[sanathkr]

@buggy Good idea! This has come up several times before in the Typescript context.

The command you mentioned involves detecting the specific typescript file as well. Is there a more generic command/solution that works even if the project doesn't use Typescript? Alternatively we can create one Typescript builder & one generic webpack builder.

We should also think about if and how the built artifacts can be used to debug. If we have to produce additional artifacts like say sourcemaps for debugging, we should also support that (may be as a v2 if its hard).

Would you be able to send a PR? We can help you take this forward.

[buggy]

The command you mentioned involves detecting the specific typescript file as well. Is there a more generic command/solution that works even if the project doesn't use Typescript? Alternatively we can create one Typescript builder & one generic webpack builder.

@sanathkr The proposal is generic. I've used app.ts in my example but you would replace that with the name of the handler function from the template.yaml. If someone was using Babel instead of TypeScript and their handler was called src/handler.js then the command would become:

npx webpack-cli src/handler.js -o ../.aws-ts/build/HelloWorldFunction/app.js --config ./webpack.config.js

Developers would control the build process using the webpack.config.js allowing them to select the loaders they want to use (i.e. TypeScript, Babel, etc). I think we can provide one template with support for both TypeScript and Babel along with documentation for removing each if they only want one.

We should also think about if and how the built artifacts can be used to debug. If we have to produce additional artifacts like say sourcemaps for debugging, we should also support that (may be as a v2 if its hard).

The standard approach is to build sourcemaps and use https://www.npmjs.com/package/source-map-support. It's something I would want to support immediately. The developer just needs to include it at the top of their handler.

Would you be able to send a PR? We can help you take this forward.

Are there instructions somewhere for how to do local development for aws-lamba-builders and aws-sam-cli? Specifically, how to get aws-sam-cli to use my local instance of aws-lamba-builders?

[sanathkr]

Awesome! Makes sense.

Actually I just realized we didn't write down these instructions. Let me do it for you tomorrow. It's quite simple actually.

[buggy]

@sanathkr I was looking at this over the weekend and I don't think a dedicated builder is required but I need to figure out why adding a prepack script to the package.json fails when "npm pack" is executed during "sam build" but works if you use "npm pack".

If I can sort that out then the we just need a new template to get webpack working.

[jfuss]

@buggy I just submitted a PR on how to do local testing through SAM CLI in #119. For this issue, it may require changes to SAM CLI too for testing the full workflow (if there is a new files we need to detect or a new workflow).

[buggy]

After looking into this I've decided to go a different direction and use Webpack to handle the sam build process. I've now released a Webpack plugin to help others https://github.com/buggy/aws-sam-webpack-plugin

Once Webpack completes the build your can use sam package / sam deploy / sam local invoke / etc as usual. It also outputs the VS Code debugging configuration for your Lambda :)