{"id":13403181,"url":"https://github.com/serverless-heaven/serverless-webpack","last_synced_at":"2025-05-12T13:18:14.992Z","repository":{"id":10469049,"uuid":"65856000","full_name":"serverless-heaven/serverless-webpack","owner":"serverless-heaven","description":"Serverless plugin to bundle your lambdas with Webpack","archived":false,"fork":false,"pushed_at":"2025-05-12T00:14:13.000Z","size":27801,"stargazers_count":1730,"open_issues_count":110,"forks_count":416,"subscribers_count":30,"default_branch":"master","last_synced_at":"2025-05-12T13:17:37.903Z","etag":null,"topics":["babel","serverless","serverless-offline","serverless-plugin","webpack","webpack-configuration","webpack2","webpack3"],"latest_commit_sha":null,"homepage":"","language":"JavaScript","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/serverless-heaven.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null,"zenodo":null}},"created_at":"2016-08-16T21:50:03.000Z","updated_at":"2025-05-12T00:14:17.000Z","dependencies_parsed_at":"2024-01-08T02:41:13.512Z","dependency_job_id":"5f593c6f-0bed-412a-9bf5-692dbfebd150","html_url":"https://github.com/serverless-heaven/serverless-webpack","commit_stats":{"total_commits":1476,"total_committers":120,"mean_commits":12.3,"dds":0.4153116531165312,"last_synced_commit":"a8c21b9e555fe071265d3f61f54ccbef06c8a1df"},"previous_names":["elastic-coders/serverless-webpack"],"tags_count":67,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/serverless-heaven%2Fserverless-webpack","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/serverless-heaven%2Fserverless-webpack/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/serverless-heaven%2Fserverless-webpack/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/serverless-heaven%2Fserverless-webpack/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/serverless-heaven","download_url":"https://codeload.github.com/serverless-heaven/serverless-webpack/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":253745196,"owners_count":21957319,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["babel","serverless","serverless-offline","serverless-plugin","webpack","webpack-configuration","webpack2","webpack3"],"created_at":"2024-07-30T19:01:26.474Z","updated_at":"2025-05-12T13:18:14.942Z","avatar_url":"https://github.com/serverless-heaven.png","language":"JavaScript","readme":"# Serverless Webpack\n\n[![Serverless][ico-serverless]][link-serverless]\n[![License][ico-license]][link-license]\n[![NPM][ico-npm]][link-npm]\n[![Build Status][ico-build]][link-build]\n[![Coverage Status][ico-coverage]][link-coverage]\n[![Contributors][ico-contributors]][link-contributors]\n\nA Serverless Framework plugin to build your lambda functions with [Webpack][link-webpack].\n\nThis plugin is for you if you want to use the latest Javascript version with [Babel][link-babel];\nuse custom [resource loaders][link-webpack-loaders], optimize your packaged functions individually\nand much more!\n\n## Highlights\n\n- Configuration possibilities range from zero-config to fully customizable\n- Support of `serverless package`, `serverless deploy` and `serverless deploy function`\n- Support of `serverless invoke local` and `serverless invoke local --watch`\n- Support of `serverless run` and `serverless run --watch`\n- Integrates with [`serverless-offline`][link-serverless-offline] to simulate local API Gateway endpoints\n- When enabled in your service configuration, functions are packaged and compiled\n  individually, resulting in smaller Lambda packages that contain only the code and\n  dependencies needed to run the function. This allows the plugin to fully utilize\n  WebPack's [Tree-Shaking][link-webpack-tree] optimization.\n- Webpack version 3, 4 and 5 support\n- Support NPM and Yarn for packaging\n- Support asynchronous webpack configuration\n\nFor the complete release notes see the end of this document.\n\n## Install\n\n```bash\n$ npm install serverless-webpack --save-dev\n```\n\nor\n\n```bash\n$ yarn add serverless-webpack --dev\n```\n\nAdd the plugin to your `serverless.yml` file:\n\n```yaml\nplugins:\n  - serverless-webpack\n```\n\n## Serverless v4 requirement\n\nIf you are using Serverless v4 you must disable the default builtin ESBuild support in your `serverless.yml` (because it conflicts with `serverless-webpack`):\n\n```yml\nbuild:\n  esbuild: false\n```\n\n## Configure\n\nThe configuration of the plugin is done by defining a `custom: webpack` object in your `serverless.yml` with your specific configuration. All settings are optional and will be set to reasonable defaults if missing.\n\nSee the sections below for detailed descriptions of the settings. The defaults are:\n\n```yaml\ncustom:\n  webpack:\n    webpackConfig: 'webpack.config.js' # Name of webpack configuration file\n    includeModules: false # Node modules configuration for packaging\n    packager: 'npm' # Packager that will be used to package your external modules\n    excludeFiles: src/**/*.test.js # Provide a glob for files to ignore\n```\n\n### Webpack configuration file\n\nBy default the plugin will look for a `webpack.config.js` in the service directory. Alternatively, you can specify a different file or configuration in `serverless.yml`.\n\n```yaml\ncustom:\n  webpack:\n    webpackConfig: ./folder/my-webpack.config.js\n```\n\nA base Webpack configuration might look like this:\n\n```js\n// webpack.config.js\n\nmodule.exports = {\n  entry: './handler.js',\n  target: 'node',\n  module: {\n    loaders: [ ... ]\n  }\n};\n```\n\nAlternatively the Webpack configuration can export an asynchronous object (e.g. a promise or async function) which will be awaited by the plugin and resolves to the final configuration object. This is useful if the confguration depends on asynchronous functions, for example, defining the AccountId of the current aws user inside AWS lambda@edge which does not support defining normal process environment variables.\n\nA basic Webpack promise configuration might look like this:\n\n```js\n// Version if the local Node.js version supports async/await\n// webpack.config.js\n\nconst webpack = require('webpack')\nconst slsw = require('serverless-webpack');\n\nmodule.exports = (async () =\u003e {\n  const accountId = await slsw.lib.serverless.providers.aws.getAccountId();\n  return {\n    entry: './handler.js',\n    target: 'node',\n    plugins: [\n      new webpack.DefinePlugin({\n        AWS_ACCOUNT_ID: `${accountId}`,\n      }),\n    ],\n    module: {\n      loaders: [ ... ]\n    }\n  };\n})();\n```\n\n```js\n// Version with promises\n// webpack.config.js\n\nconst webpack = require('webpack')\nconst slsw = require('serverless-webpack');\nconst BbPromise = require('bluebird');\n\nmodule.exports = BbPromise.try(() =\u003e {\n  return slsw.lib.serverless.providers.aws.getAccountId()\n  .then(accountId =\u003e ({\n    entry: './handler.js',\n    target: 'node',\n    plugins: [\n      new webpack.DefinePlugin({\n        AWS_ACCOUNT_ID: `${accountId}`,\n      }),\n    ],\n    module: {\n      loaders: [ ... ]\n    }\n  }));\n});\n```\n\n### serverless-webpack lib export helper\n\nserverless-webpack exposes a lib object, that can be used in your webpack.config.js\nto make the configuration easier and to build fully dynamic configurations.\nThis is the preferred way to configure webpack - the plugin will take care of\nas much of the configuration (and subsequent changes in your services) as it can.\n\n#### Automatic entry resolution\n\nYou can let the plugin determine the correct handler entry points at build time.\nThen you do not have to care anymore when you add or remove functions from your service:\n\n```js\n// webpack.config.js\nconst slsw = require('serverless-webpack');\n\nmodule.exports = {\n  ...\n  entry: slsw.lib.entries,\n  ...\n};\n```\n\nCustom entries that are not part of the SLS build process can be added too:\n\n```js\n// webpack.config.js\nconst _ = require('lodash');\nconst slsw = require('serverless-webpack');\n\nmodule.exports = {\n  ...\n  entry: _.assign({\n    myCustomEntry1: './custom/path/something.js'\n  }, slsw.lib.entries),\n  ...\n};\n```\n\n##### Optional entry overrides\n\n`serverless-webpack` generates Webpack entries from the `handler` value by default.\n\nIf your handler is different from the webpack entry, e.g. provided by a layer,\nyou may override the generated entry at function level via the `entrypoint`\noption in `serverless.yml`.\n\n```yaml\nfunctions:\n  my-function:\n    layers:\n      - LAYER-ARN\n    handler: layer.handler\n    entrypoint: src/index.handler\n```\n\n#### Full customization (for experts)\n\nThe lib export also provides the `serverless` and `options` properties, through\nwhich you can access the Serverless instance and the options given on the command-line.\n\nThe current stage e.g is accessible through `slsw.lib.options.stage`\n\nThis enables you to have a fully customized dynamic configuration, that can evaluate\nanything available in the Serverless framework. There are really no limits.\n\nSamples are: The current stage and the complete service definition. You thereby\nhave access to anything that a Serverless plugin would have access to.\n\nBoth properties should be handled with care and should never be written to,\nas that will modify the running framework and leads to unpredictable behavior!\n\nIf you have cool use cases with the full customization, we might add your solution\nto the plugin examples as showcase.\n\n#### Invocation state\n\n`lib.webpack` contains state variables that can be used to configure the build\ndynamically on a specific plugin state.\n\n##### isLocal\n\n`lib.webpack.isLocal` is a boolean property that is set to true, if any known\nmechanism is used in the current Serverless invocation that runs code locally.\n\nThis allows to set properties in the webpack configuration differently depending\nif the lambda code is run on the local machine or deployed.\n\nA sample is to set the compile mode with Webpack 4:\n\n```\nmode: slsw.lib.webpack.isLocal ? \"development\" : \"production\"\n```\n\n### Output\n\nNote that, if the `output` configuration is not set, it will automatically be\ngenerated to write bundles in the `.webpack` directory. If you set your own `output`\nconfiguration make sure to add a [`libraryTarget`][link-webpack-libtarget]\nfor best compatibility with external dependencies:\n\n```js\n// webpack.config.js\nconst path = require('path');\n\nmodule.exports = {\n  // ...\n  output: {\n    libraryTarget: 'commonjs',\n    path: path.resolve(__dirname, '.webpack'),\n    filename: '[name].js'\n  }\n  // ...\n};\n```\n\n### Stats\n\nBy default, the plugin will print a quite verbose bundle information to your console. However, if\nyou are not satisfied with the current output info, you can overwrite it in your `webpack.config.js`\n\n```js\n// webpack.config.js\n\nmodule.exports = {\n  // ...\n  stats: 'minimal'\n  // ...\n};\n```\n\nAll the stats config can be found in [webpack's documentation][link-webpack-stats]\n\n### Node modules / externals\n\nBy default, the plugin will try to bundle all dependencies. However, you don't\nwant to include all modules in some cases such as selectively import, excluding\nbuiltin package (ie: `aws-sdk`) and handling webpack-incompatible modules.\n\nIn this case you might add external modules in\n[Webpack's `externals` configuration][link-webpack-externals].\nThose modules can be included in the Serverless bundle with the `custom: webpack: includeModules`\noption in `serverless.yml`:\n\n```js\n// webpack.config.js\nvar nodeExternals = require('webpack-node-externals');\n\nmodule.exports = {\n  // we use webpack-node-externals to excludes all node deps.\n  // You can manually set the externals too.\n  externals: [nodeExternals()]\n};\n```\n\n```yaml\n# serverless.yml\ncustom:\n  webpack:\n    includeModules: true # enable auto-packing of external modules\n```\n\nAll modules stated in `externals` will be excluded from bundled files. If an excluded module\nis stated as `dependencies` in `package.json` and it is used by the webpack chunk, it will be\npacked into the Serverless artifact under the `node_modules` directory.\n\nBy default, the plugin will use the `package.json` file in working directory, If you want to\nuse a different package file, set `packagePath` to your custom `package.json`:\n\n```yaml\n# serverless.yml\ncustom:\n  webpack:\n    includeModules:\n      packagePath: '../package.json' # relative path to custom package.json file.\n```\n\n\u003e Note that only relative path is supported at the moment.\n\n`peerDependencies` of all above external dependencies will also be packed into the Serverless\nartifact. By default, `node_modules` in the same directory as `package.json` (current working directory\nor specified by`packagePath`) will be used.\n\nHowever in some configuration (like monorepo), `node_modules` is in parent directory which is different from\nwhere `package.json` is. Set `nodeModulesRelativeDir` to specify the relative directory where `node_modules` is.\n\n```yaml\n# serverless.yml\ncustom:\n  webpack:\n    includeModules:\n      nodeModulesRelativeDir: '../../' # relative path to current working directory.\n```\n\nWhen using NPM 8, `peerDependencies` are automatically installed by default. In order to avoid adding all transitive dependencies to your `package.json`, we will use the `package-lock.json` when possible. If your project is included in a monorepo, you can specify the path to the `package-lock.json`:\n\n```yaml\n# serverless.yml\ncustom:\n  webpack:\n    includeModules:\n      nodeModulesRelativeDir: '../../' # relative path to current working directory.\n    packagerOptions:\n      lockFile: '../../package-lock.json' # relative path to package-lock.json\n```\n#### Runtime dependencies\n\nIf a runtime dependency is detected that is found in the `devDependencies` section and\nso would not be packaged, the plugin will error until you explicitly exclude it (see `forceExclude` below)\nor move it to the `dependencies` section.\n\n#### AWS-SDK\n\nAn exception for the runtime dependency error is the AWS-SDK. All projects using the AWS-SDK normally\nhave it listed in `devDependencies` because AWS provides it already in their Lambda environment. In this case\nthe aws-sdk is automatically excluded and only an informational message is printed (in `--verbose` mode).\n\nThe main reason for the warning is, that silently ignoring anything contradicts the declarative nature\nof Serverless' service definition. So the correct way to define the handling for the aws-sdk is, as\nyou would do for all other excluded modules (see `forceExclude` below).\n\n```yaml\n# serverless.yml\ncustom:\n  webpack:\n    includeModules:\n      forceExclude:\n        - aws-sdk\n```\n\n#### Packagers\n\nYou can select the packager that will be used to package your external modules.\nThe packager can be set with the packager configuration. Currently it can be 'npm'\nor 'yarn' and defaults to using npm when not set.\n\n```yaml\n# serverless.yml\ncustom:\n  webpack:\n    packager: 'yarn' # Defaults to npm\n    packagerOptions: {} # Optional, depending on the selected packager\n```\n\nYou should select the packager, that you use to develop your projects, because only\nthen locked versions will be handled correctly, i.e. the plugin uses the generated\n(and usually committed) package lock file that is created by your favorite packager.\n\nEach packager might support specific options that can be set in the `packagerOptions`\nconfiguration setting. For details see below.\n\n##### NPM\n\nBy default, the plugin uses NPM to package the external modules. However, if you use npm,\nyou should use any version `\u003c5.5 \u003e=5.7.1` as the versions in-between have some nasty bugs.\n\nThe NPM packager supports the following `packagerOptions`:\n\n| Option                  | Type     | Default             | Description                                                         |\n|-------------------------|----------|---------------------|---------------------------------------------------------------------|\n| ignoreScripts           | bool     | false               | Do not execute package.json hook scripts on install                 |\n| noInstall               | bool     | false               | Do not run `npm install` (assume install completed)                 |\n| lockFile                | string   | ./package-lock.json | Relative path to lock file to use                                   |\n| copyPackageSectionNames | string[] | []                  | Entries in your `package.json` to copy to the output `package.json` (ie: ESM output) |\n\nWhen using NPM version `\u003e= 7.0.0`, we will use the `package-lock.json` file instead of modules installed in `node_modules`. This improves the\nsupports of NPM `\u003e= 8.0.0` which installs `peer-dependencies` automatically. The plugin will be able to detect the correct version.\n\n###### ESM output\n\nIf you need to generate ESM output, and you cannot safely produce a `.mjs` file\n(e.g. [because that breaks serverless-offline](https://github.com/serverless/serverless/issues/11308)),\nyou can use `copyPackageSectionNames` to ensure the output `package.json` defaults to ESM.\n\n```yaml\ncustom:\n  webpack:\n    packagerOptions:\n      copyPackageSectionNames:\n        - type\n        - exports\n        - main\n```\n\n##### Yarn\n\nUsing yarn will switch the whole packaging pipeline to use yarn, so does it use a `yarn.lock` file.\n\nThe yarn packager supports the following `packagerOptions`:\n\n| Option                  | Type     | Default         | Description                                                         |\n|-------------------------|----------|-----------------|---------------------------------------------------------------------|\n| ignoreScripts           | bool     | false           | Do not execute package.json hook scripts on install                 |\n| noInstall               | bool     | false           | Do not run `yarn install` (assume install completed)                |\n| noNonInteractive        | bool     | false           | Disable interactive mode when using Yarn 2 or above                 |\n| noFrozenLockfile        | bool     | false           | Do not require an up-to-date yarn.lock                              |\n| networkConcurrency      | int      |                 | Specify number of concurrent network requests                       |\n| copyPackageSectionNames | string[] | ['resolutions'] | Entries in your `package.json` to copy to the output `package.json` |\n\n##### Common packager options\n\nThere are some settings that are common to all packagers and affect the packaging itself.\n\n###### Custom scripts\n\nYou can specify custom scripts that are executed after the installation of the function/service packages\nhas been finished. These are standard packager scripts as they can be used in any `package.json`.\n\nWarning: The use cases for them are very rare and specific and you should investigate first,\nif your use case can be covered with webpack plugins first. They should never access files\noutside of their current working directory which is the compiled function folder, if any.\nA valid use case would be to start anything available as binary from `node_modules`.\n\n```yaml\ncustom:\n  webpack:\n    packagerOptions:\n      scripts:\n        - npm rebuild grpc --target=6.1.0 --target_arch=x64 --target_platform=linux --target_libc=glibc\n```\n\n#### Forced inclusion\n\nSometimes it might happen that you use dynamic requires in your code, i.e. you\nrequire modules that are only known at runtime. Webpack is not able to detect\nsuch externals and the compiled package will miss the needed dependencies.\nIn such cases you can force the plugin to include certain modules by setting\nthem in the `forceInclude` array property. However the module must appear in\nyour service's production dependencies in `package.json`.\n\n```yaml\n# serverless.yml\ncustom:\n  webpack:\n    includeModules:\n      forceInclude:\n        - module1\n        - module2\n```\n\n#### Forced exclusion\n\nYou can forcefully exclude detected external modules, e.g. if you have a module\nin your dependencies that is already installed at your provider's environment.\n\nJust add them to the `forceExclude` array property and they will not be packaged.\n\n```yaml\n# serverless.yml\ncustom:\n  webpack:\n    includeModules:\n      forceExclude:\n        - module1\n        - module2\n```\n\nIf you specify a module in both arrays, `forceInclude` and `forceExclude`, the\nexclude wins and the module will not be packaged.\n\n#### Local modules\n\nYou can use `file:` version references in your `package.json` to use a node module\nfrom a local folder (e.g. `\"mymodule\": \"file:../../myOtherProject/mymodule\"`).\nWith that you can do test deployments from the local machine with different\nmodule versions or modules before they are published officially.\n\n#### Exclude Files with similar names\n\nIf you have a project structure that uses something like `index.js` and a\nco-located `index.test.js` then you have likely seen an error like:\n`WARNING: More than one matching handlers found for index. Using index.js`\n\nThis config option allows you to exclude files that match a glob from function\nresolution. Just add: `excludeFiles: **/*.test.js` (with whatever glob you want\nto exclude).\n\n```yaml\n# serverless.yml\ncustom:\n  webpack:\n    excludeFiles: **/*.test.js\n```\n\nThis is also useful for projects that use TypeScript.\n\n#### Exclude Files with Regular Expression\n\nThis config option allows you to filter files that match a regex pattern before\nadding to the zip file. Just add: `excludeRegex: \\.ts|test|\\.map` (with whatever\nregex you want to exclude).\n\n```yaml\n# serverless.yml\ncustom:\n  webpack:\n    excludeRegex: \\.ts|test|\\.map\n```\n\n#### Keep output directory after packaging\n\nYou can keep the output directory (defaults to `.webpack`) from being removed\nafter build.\n\nJust add `keepOutputDirectory: true`\n\n```yaml\n# serverless.yml\ncustom:\n  webpack:\n    keepOutputDirectory: true\n```\n\nThis can be useful, in case you want to upload the source maps to your Error\nreporting system, or just have it available for some post processing.\n\n#### Nodejs custom runtime\n\nIf you are using a nodejs custom runtime you can add the property `allowCustomRuntime: true`.\n\n```yaml\nexampleFunction:\n  handler: path/to/your/handler.default\n  runtime: provided\n  allowCustomRuntime: true\n```\n\n⚠️ **Note: this will only work if your custom runtime and function are written in JavaScript.\nMake sure you know what you are doing when this option is set to `true`**\n\n#### Examples\n\nYou can find an example setups in the [`examples`][link-examples] folder.\n\n#### Service level packaging\n\nIf you do not enable individual packaging in your service (serverless.yml), the\nplugin creates one ZIP file for all functions (the service package) that includes\nall node modules used in the service. This is the fastest packaging, but not the\noptimal one, as node modules are always packaged, that are not needed by some\nfunctions.\n\n#### Optimization / Individual packaging per function\n\nA better way to do the packaging, is to enable individual packaging in your\nservice:\n\n```yaml\n# serverless.yml\n---\npackage:\n  individually: true\n```\n\nThis will switch the plugin to per function packaging which makes use of the multi-compiler\nfeature of Webpack. That means, that Webpack compiles **and optimizes** each\nfunction individually, removing unnecessary imports and reducing code sizes\nsignificantly. Tree-Shaking only makes sense with this approach.\n\nNow the needed external node modules are also detected by Webpack per function\nand the plugin only packages the needed ones into the function artifacts. As a\nresult, the deployed artifacts are smaller, depending on the functions and\ncold-start times (to install the functions into the cloud at runtime) are reduced\ntoo.\n\nThe individual packaging will automatically apply the _automatic entry resolution_ (see above) and\nyou will not be able to configure the entry config in webpack. An error will be thrown\nif you are trying to override the entry in webpack.config.js with other unsupported values.\n\nThe individual packaging needs more time at the packaging phase, but you'll\nget that paid back twice at runtime.\n\n#### Individual packaging concurrency\n\n```yaml\n# serverless.yml\ncustom:\n  webpack:\n    concurrency: 5 # desired concurrency, defaults to the number of available cores\n    serializedCompile: true # backward compatible, this translates to concurrency: 1\n```\n\nWill run each webpack build one at a time which helps reduce memory usage and in some cases impoves overall build performance.\n\n### Support for Docker Images as Custom Runtimes\n\nAWS Lambda and `serverless` started supporting the use of Docker images as custom runtimes in 2021. See the [serverless documentation](https://www.serverless.com/blog/container-support-for-lambda) for details on how to configure a `serverless.yml` to use these features.\n\n**NOTE: You must provide an override for the Image `CMD` property in your function definitions.**\nSee [Dockerfile documentation](https://docs.docker.com/engine/reference/builder/#cmd) for more information about the native Docker `CMD` property.\n\nIn the following example `entrypoint` is inherited from the shared Docker image, while `command` is provided as an override for each function:\n\n```yaml\n# serverless.yml\nfunctions:\n  myFunction1:\n    image:\n      name: public.ecr.aws/lambda/nodejs:12\n      command:\n        - app.handler1\n  myFunction2:\n    image:\n      name: public.ecr.aws/lambda/nodejs:12\n      command:\n        - app.handler2\n```\n\nIf you want to use a remote docker image but still need the webpack process before doing so, you can specify it as indicated below:\n\n```yaml\n# serverless.yml\nfunctions:\n  myFunction1:\n    image: public.ecr.aws/lambda/nodejs:latest\n```\n\n## Usage\n\n### Automatic bundling\n\nThe normal Serverless deploy procedure will automatically bundle with Webpack:\n\n- Create the Serverless project with `serverless create -t aws-nodejs`\n- Install Serverless Webpack as above\n- Deploy with `serverless deploy`\n\n### Run a function locally\n\nThe plugin fully integrates with `serverless invoke local`. To run your bundled functions\nlocally you can:\n\n```bash\n$ serverless invoke local --function \u003cfunction-name\u003e\n```\n\nAll options that are supported by invoke local can be used as usual:\n\n- `--function` or `-f` (required) is the name of the function to run\n- `--path` or `-p` (optional) is a JSON file path used as the function input event\n- `--data` or `-d` (optional) inline JSON data used as the function input event\n\n\u003e :exclamation: The old `webpack invoke` command has been disabled.\n\n#### Run a function with an existing compiled output\n\nOn CI systems it is likely that you'll run multiple integration tests with `invoke local`\nsequentially. To improve this, you can do one compile and run multiple invokes on the\ncompiled output - it is not necessary to compile again before each and every invoke.\n\n##### Using the CLI option `--skip-build`\n\n```bash\n$ serverless webpack\n$ serverless invoke local --function \u003cfunction-name-1\u003e --skip-build\n$ serverless invoke local --function \u003cfunction-name-2\u003e --skip-build\n```\n\n##### Using the parameter `noBuild`\n\n```yaml\ncustom:\n  webpack:\n    noBuild: true\n```\n\n### Run a function locally on source changes\n\nOr to run a function every time the source files change use the `--watch` option\ntogether with `serverless invoke local`:\n\n```bash\n$ serverless invoke local --function \u003cfunction-name\u003e --path event.json --watch\n```\n\nEverytime the sources are changed, the function will be executed again with the\nchanged sources. The command will watch until the process is terminated.\n\nIf you have your sources located on a file system that does not offer events,\nyou can enable polling with the `--webpack-use-polling=\u003ctime in ms\u003e` option.\nIf you omit the value, it defaults to 3000 ms.\n\nAll options that are supported by invoke local can be used as usual:\n\n- `--function` or `-f` (required) is the name of the function to run\n- `--path` or `-p` (optional) is a JSON file path used as the function input event\n- `--data` or `-d` (optional) inline JSON data used as the function input event\n\n\u003e :exclamation: The old `webpack watch` command has been disabled.\n\n### Usage with serverless run (Serverless Event Gateway)\n\nThe `serverless run` command is supported with the plugin. To test a local\nservice with the Serverless Emulator, you can use the `serverless run`\ncommand as documented by Serverless. The command will compile the code before\nit uploads it into the event gateway.\n\n#### Serverless run with webpack watch mode\n\nYou can enable source watch mode with `serverless run --watch`. The plugin will\nthen watch for any source changes, recompile and redeploy the code to the event\ngateway. So you can just keep the event gateway running and test new code immediately.\n\n### Usage with serverless-offline\n\nThe plugin integrates very well with [serverless-offline][link-serverless-offline] to\nsimulate AWS Lambda and AWS API Gateway locally.\n\nAdd the plugins to your `serverless.yml` file and make sure that `serverless-webpack`\nprecedes `serverless-offline` as the order is important:\n\n```yaml\nplugins: ...\n  - serverless-webpack\n  ...\n  - serverless-offline\n  ...\n```\n\nRun `serverless offline` or `serverless offline start` to start the Lambda/API simulation.\n\nIn comparison to `serverless offline`, the `start` command will fire an `init` and a `end` lifecycle hook which is needed for `serverless-offline` and e.g. `serverless-dynamodb-local` to switch off resources (see below).\n\nYou can find an example setup in the [`examples`][link-examples] folder.\n\nBy default the plugin starts in watch mode when triggered through `serverless offline`, i.e.\nit automatically recompiles your code if it detects a change in the used sources.\nAfter a change it might take some seconds until the emulated endpoints are updated.\n\nIf you have your sources located on a file system that does not offer events,\ne.g. a mounted volume in a Docker container, you can enable polling with the\n`--webpack-use-polling=\u003ctime in ms\u003e` option. If you omit the value, it defaults\nto 3000 ms.\n\nIf you don't want the plugin to build when using `serverless-offline`, select the `--skip-build` option.\n\n#### Custom paths\n\nIf you do not use the default path and override it in your Webpack configuration,\nyou have use the `--location` option.\n\n#### serverless-dynamodb-local\n\nConfigure your service the same as mentioned above, but additionally add the `serverless-dynamodb-local`\nplugin as follows:\n\n```yaml\nplugins:\n  - serverless-webpack\n  - serverless-dynamodb-local\n  - serverless-offline\n```\n\nRun `serverless offline start`.\n\n#### Other useful options\n\nYou can disable timeouts with `--noTimeout` when using `serverless-offline`.\n\nIf you use serverless offline to run your integration tests, you might want to\ndisable the automatic watch mode with the `--webpack-no-watch` switch.\n\n### Bundle with webpack\n\nTo just bundle and see the output result use:\n\n```bash\n$ serverless webpack --out dist\n```\n\nOptions are:\n\n- `--out` or `-o` (optional) The output directory. Defaults to `.webpack`.\n\n### Simulate API Gateway locally\n\n:exclamation: The serve command has been removed. See above how to achieve the\nsame functionality with the [`serverless-offline`][link-serverless-offline] plugin.\n\n### vscode debugging\n\nTo debug your functions using `serverless invoke local` or `serverless-offline`\ncheck this [`.vscode/launch.json example`][link-examples-babel-webpack-4-vscode-launch].\n\n## Example with Babel\n\nIn the [`examples`][link-examples] folder there is a Serverless project using this\nplugin with Babel. To try it, from inside the example folder:\n\n- `npm install` to install dependencies\n- `serverless invoke local -f hello` to run the example function\n\n## Provider Support\n\nPlugin commands are supported by the following providers. ⁇ indicates that command has not been tested with that provider.\n\n|                      | AWS Lambda | Apache OpenWhisk | Azure Functions | Google Cloud Functions |\n| -------------------- | ---------- | ---------------- | --------------- | ---------------------- |\n| webpack              | ✔︎         | ✔︎               | ⁇               | ⁇                      |\n| invoke local         | ✔︎         | ✔︎               | ⁇               | ⁇                      |\n| invoke local --watch | ✔︎         | ✔︎               | ⁇               | ⁇                      |\n\n## Plugin support\n\nThe following serverless plugins are explicitly supported with `serverless-webpack`\n\n| Plugin                            | NPM                                                               |\n| --------------------------------- | ----------------------------------------------------------------- |\n| serverless-offline                | [![NPM][ico-serverless-offline]][link-serverless-offline]         |\n| serverless-step-functions-offline | [![NPM][ico-step-functions-offline]][link-step-functions-offline] |\n\n## For developers\n\nThe plugin exposes a complete lifecycle model that can be hooked by other plugins to extend\nthe functionality of the plugin or add additional actions.\n\n### The event lifecycles and their hookable events (H)\n\nAll events (H) can be hooked by a plugin.\n\n```\n-\u003e webpack:validate\n   -\u003e webpack:validate:validate (H)\n-\u003e webpack:compile\n   -\u003e webpack:compile:compile (H)\n   -\u003e webpack:compile:watch:compile (H)\n-\u003e webpack:package\n   -\u003e webpack:package:packExternalModules (H)\n   -\u003e webpack:package:packageModules (H)\n```\n\n### Integration of the lifecycles into the command invocations and hooks\n\nThe following list shows all lifecycles that are invoked/started by the\nplugin when running a command or invoked by a hook.\n\n```\n-\u003e before:package:createDeploymentArtifacts\n   -\u003e webpack:validate\n   -\u003e webpack:compile\n   -\u003e webpack:package\n\n-\u003e before:deploy:function:packageFunction\n   -\u003e webpack:validate\n   -\u003e webpack:compile\n   -\u003e webpack:package\n\n-\u003e before:invoke:local:invoke\n   -\u003e webpack:validate\n   -\u003e webpack:compile\n\n-\u003e webpack\n   -\u003e webpack:validate\n   -\u003e webpack:compile\n   -\u003e webpack:package\n\n-\u003e before:offline:start\n   -\u003e webpack:validate\n   -\u003e webpack:compile\n\n-\u003e before:offline:start:init\n   -\u003e webpack:validate\n   -\u003e webpack:compile\n```\n\n## Thanks\n\nSpecial thanks go to the initial author of serverless-webpack, [Nicola Peduzzi](https://github.com/thenikso), who allowed\nme to take it over and continue working on the project. That helped to revive it and lead it to new horizons.\n\n## Release Notes\n\nSee [the releases section](https://github.com/serverless-heaven/serverless-webpack/releases)\n\n[ico-serverless]: http://public.serverless.com/badges/v3.svg\n[ico-license]: https://img.shields.io/github/license/serverless-heaven/serverless-webpack.svg\n[ico-npm]: https://img.shields.io/npm/v/serverless-webpack.svg\n[ico-build]: https://github.com/serverless-heaven/serverless-webpack/actions/workflows/tests.yml/badge.svg\n[ico-coverage]: https://coveralls.io/repos/github/serverless-heaven/serverless-webpack/badge.svg?branch=master\n[ico-contributors]: https://img.shields.io/github/contributors/serverless-heaven/serverless-webpack.svg\n[link-serverless]: https://www.serverless.com/\n[link-license]: ./blob/master/LICENSE\n[link-npm]: https://www.npmjs.com/package/serverless-webpack\n[link-build]: https://github.com/serverless-heaven/serverless-webpack/actions/workflows/tests.yml\n[link-coverage]: https://coveralls.io/github/serverless-heaven/serverless-webpack?branch=master\n[link-contributors]: https://github.com/serverless-heaven/serverless-webpack/graphs/contributors\n[link-webpack]: https://webpack.github.io/\n[link-babel]: https://babeljs.io/\n[link-webpack-stats]: https://webpack.js.org/configuration/stats/\n[link-webpack-loaders]: https://webpack.js.org/concepts/loaders/\n[link-webpack-libtarget]: https://webpack.js.org/configuration/output/#output-librarytarget\n[link-webpack-tree]: https://webpack.js.org/guides/tree-shaking/\n[link-webpack-externals]: https://webpack.js.org/configuration/externals/\n[link-examples]: ./examples\n[link-examples-babel-webpack-4-vscode-launch]: ./examples/babel-webpack-4/.vscode/launch.json\n[link-serverless-offline]: https://www.npmjs.com/package/serverless-offline\n[ico-serverless-offline]: https://img.shields.io/npm/v/serverless-offline.svg\n[link-serverless-dynamodb-local]: https://www.npmjs.com/package/serverless-dynamodb-local\n[link-step-functions-offline]: https://www.npmjs.com/package/serverless-step-functions-offline\n[ico-step-functions-offline]: https://img.shields.io/npm/v/serverless-step-functions-offline.svg\n","funding_links":[],"categories":["JavaScript"],"sub_categories":[],"project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fserverless-heaven%2Fserverless-webpack","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fserverless-heaven%2Fserverless-webpack","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fserverless-heaven%2Fserverless-webpack/lists"}