serverless-heaven / serverless-webpack

Serverless plugin to bundle your lambdas with Webpack

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

v2.2.0 -> v2.2.1 broke my deployment workflow

bebbi opened this issue · comments

This is a (Bug Report / Feature Proposal)

Bug

Description

serverless-webpack@2.2.0 (and all versions before):

serverless webpack bundles into the path .webpack/handler.js

serverless-webpack@2.2.1

serverless webpack bundles into the path .webpack/main.js

No handler.js, and all functions relying on webpack don't work anymore.
(serverless deploy, serverless offline start, serverless webpack ..)

For bug reports:

  • What went wrong?
    serverless-webpack bundles into main.js
  • What did you expect should have happened?
    serverless-webpack bundles into handler.js
  • What was the config you used?
    The same as ever. Change easily observable here when installing 2.2.0 vs 2.2.1
    and running serverless webpack. The output with 2.2.1 is:
Serverless: Bundling with Webpack...
Time: 2379ms
  Asset    Size  Chunks             Chunk Names
main.js  222 kB       0  [emitted]  main

vs 2.2.0:

Serverless: Bundling with Webpack...
Time: 2670ms
     Asset    Size  Chunks             Chunk Names
handler.js  222 kB       0  [emitted]  main
  • What stacktrace or error message from your provider did you see?

For feature proposals:

  • What is the use case that should be solved. The more detail you describe this in the easier it is to understand for us.
  • If there is additional config how would it look

Similar or dependent issue(s):

Additional Data

  • Serverless-Webpack Version you're using:
    2.2.1
  • Webpack version you're using:
    1.13.3
  • Serverless Framework Version you're using:
    1.19.0
  • Operating System: macos
  • Stack Trace (if available):

Thanks for creating the issue. Can you post your webpack config and the function definitions from serverless.yml? Do the function handler definitions match the actual handler files, and finally which provider do you use (AWS, Google, OpenWhisk, etc.)?

BTW: Do you see the new warning WARNING: Entry for ${name}@${handler} could not be retrieved. in your output?

config:

var nodeExternals = require('webpack-node-externals')

module.exports = {
  entry: './handler.js',
  target: 'node',
  // exclude external modules
  externals: [nodeExternals()],
  module: {
    loaders: [
      {
        test: /\.js$/,
        loaders: ['babel'],
        include: __dirname,
        exclude: /node_modules/
      },
      {
        test: /\.json$/,
        loader: 'json'
      }
    ]
  }
}

func defs:

functions:
  wraporderflow:
    handler: handler.wrapOrderFlow
    events:
      ...
    name: ${self:provider.stage}-wraporderflow
    ...
  orderflow:
    handler: handler.orderFlow
    events:
      ...
    name: ${self:provider.stage}-orderflow
    ...
  variant:
    handler: handler.fetchVariant
    events:
      ...
    name: ${self:provider.stage}-variant
    ...

handler: yes, matching

...
export const orderFlow = asEndpoint(orderFlowLambda);

export const fetchVariant = asEndpoint(fetchVariantLambda);

export const wrapOrderFlow = asEndpoint(wrapOrderFlowLambda);

Provider: AWS

No, I don't see that warning in either version.

Ok. The only difference between 2.2.0 and 2.2.1 is the warning message to prevent a crash in case the handler entry is not parseable or not set (see git diff). There was no change in any of the other parts of the code.

I'm not sure where the changes you experience come from. What is strange is, that your chunk name is named main. This leads to an automatic generation of a main .js. See here:

      this.webpackConfig.output = {
        libraryTarget: 'commonjs',
        path: outputPath,
        filename: '[name].js',
      };

But that behavior did not change between 2.2.0 and 2.2.1

WAIT: I think the default output filename might have changed to [name].js to adapt the automatic entry point behavior! Before it used handler.js as fixed name, which is not flexible. Sorry for that - seems that commit was not published with 2.2.0 which it should have been.

What you can do is to add an explicit output configuration in your webpack config like this:

output: {
  libraryTarget: 'commonjs',
  path: path.join(__dirname, '.webpack'),
  filename: 'handler.js'
}

Or you switch to webpack 2 or webpack 3 and use the automatic entry detection with slsw.lib.entries that will automatically set up things for you.

Updated the comment above.
A sample of the automatic entry detecion can be found in the babel-dynamically-entries example.

Thanks for checking! Just quick-fixed with the output section for now.

@bebbi Ok. Thanks for the feedback. I'm not sure if I should revert the default output settings as 2.2.1 is only a bugfix release and should not change behavior or lead to failing builds. What is your opinion on that?
I could revert it and deploy a 2.2.2 with the old behavior in a short time.

Looking in more detail at the diff 2.2.0 -> 2.2.1, it looks like there is a change in behaviour. It is introduced by this diff

this.webpackConfig.output = {
  libraryTarget: 'commonjs',
  path: outputPath,
- filename: outputFilename,
+ filename: '[name].js',
};

where in 2.2.0, outputFilename is calculated as "handler.js" directly from above webpack config.

Whereas in 2.2.1, I haven't debugged what is name but it most likely is the chunk name, i.e. "main", leading to main.js.

It would probably be easiest to simply fix this part in a 2.2.2 if that's possible.

Oh, your comment update didn't show for me until now.

Maybe best to revert in 2.2.2 and update + doc in 3?

Yep I'll revert the change and release a 2.2.2

Just committed a fix and will release it now. The new behavior is pretty well documented in V3 and the now preferred automatic entry resolution as well. It was good that you've encountered it so quickly 👍

@bebbi Released! Can you do a sanity check if it now works again and then close the issue please?

works, thanks much!