Package Exports
- serverless-plugin-browserifier
This package does not declare an exports field, so the exports above have been automatically detected and optimized by JSPM instead. If any package subpath is missing, it is recommended to post an issue to the original package (serverless-plugin-browserifier) to support the "exports" field. If that is not possible, create a JSPM override to customize the exports field for this package.
Readme
Serverless Browserifier Plugin
A Serverless v1 plugin that uses Browserify to bundle your Node.js Lambda functions.
This project has been forked from the original serverless-plugin-browserify by Ryan Pendergast and published under a different name.
Motivation
Lambda functions with smaller code start and run faster.
With the example package.json
and javascript code below, the default packaging for Node.js lambdas in Serverless produces a zip file that is 11.3 MB, because it blindly includes all of node_modules
in the zip package.
This plugin with 2 lines of configuration produces a zip file that is 400 KB!
...
"dependencies": {
"aws-sdk": "^2.6.12",
"moment": "^2.15.2",
"request": "^2.75.0",
"rxjs": "^5.0.0-rc.1"
},
...
const Rx = require('rxjs/Rx');
const request = require('request');
...
Even if you choose to manually prepare your packages with package[include|exclude]
, you will still have to take care of that for each single function individually, and manually. This is specially hard after npm
3, due to dependency tree flattening.
Also, AWS Lambda has an account-wide deployment package size limit.
Mind that aws-sdk-js now officially supports browserify. Read more about this in on this article.
Installation
From your target serverless project, run:
npm install serverless-plugin-browserifier --save-dev
Add the plugin to your serverless.yml
file and set package.individually
to true
:
plugins:
- serverless-plugin-browserifier
package:
individually: true
The property package.individually
must be set because it makes configuration more straightforward, and if you are not packaging individually size is not a concern of yours in the first place.
Configuration
For most use cases you should NOT need to do any configuration. You can, however, introduce custom configuration.
The base config for browserify is read from the custom.browserify
section of serverless.yml
. All browserify options are supported (most are auto configured by this plugin). This plugin adds one special option disable
which if true
will bypass this plugin.
The base config can be overridden on a function-by-function basis. Again, custom.browserify
is not required and should not even need to be defined in most cases.
custom:
browserify:
#any option defined in https://github.com/substack/node-browserify#browserifyfiles--opts
functions:
usersGet:
name: ${self:provider.stage}-${self:service}-pageGet
description: get user
handler: users/handler.hello
browserify:
noParse:
- ./someBig.json #browserify can't optimize json, will take long time to parse for nothing
If you find a package that is not supported or does not behave well with browserify, you can still use function level package.include
to include extra modules and files to your package. That said, you are encouraged to verify if you specific case can be dealt with by leveraging all available browserify options in your serverless.yml
custom browserify
section.
Usage
When this plugin is enabled, and package.individually
is true
, running serverless deploy
and serverless deploy -f <funcName>
will automatically browserify your Node.js lambda code.
If you want to see more information about the process, simply set SLS_DEBUG=*
. Example:
$ export SLS_DEBUG=*
$ sls deploy function -v -f usersGet
FAQ
Should I use Webpack instead of this plugin?
Browserify, in general, supports more modules, optimises better (generates smaller bundles), and requires less configuration. Webpack is an amazing tool, but it comes with several extras that are not really needed within a pure Node.js environment.
What about uglification?
You should be able to use uglify-es
through uglifyify
.
And what about babel?
I believe that babelify
should do the trick, although I don't see any reason for it. AWS Lambda already supports Node.js 6.10, with enough ES-next goodies that allows us to avoid transpilers.
License
MIT License.
For the complete information, please refer to the license file.