New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make serverless-webpack more extensible #254

Merged
merged 7 commits into from Oct 23, 2017

Conversation

Projects
None yet
2 participants
@josephleehunsaker
Copy link
Contributor

josephleehunsaker commented Oct 17, 2017

What did you implement:

Use PluginManager to make serverless-webpack more extensible. I am trying to create my own plugin that works with serverless-webpack, but I am unable to extend before the validation step without this change.

Closes #XXXXX

How did you implement it:

Following the advice from serverless blog on Advanced Plugin Development. Used Plugin Manager.
https://serverless.com/blog/advanced-plugin-development-extending-the-core-lifecycle/

How can we verify it:

As stated in the blog above... this will enable better extensibility.
Try to create a new serverless plugin that runs before the serverless-webpack before:deploy:createDeploymentArtifacts hook.

Todos:

  • Write tests
  • Write documentation
  • Fix linting errors
  • Make sure code coverage hasn't dropped
  • Provide verification config / commands / resources
  • Enable "Allow edits from maintainers" for this PR
  • Update the messages below

Is this ready for review?: YES
Is it a breaking change?: NO

Make serverless-webpack more extensible
Use PluginManager to make serverless-webpack more extensible 

Following the advice from serverless blog on Advanced Plugin Development. https://serverless.com/blog/advanced-plugin-development-extending-the-core-lifecycle/
@HyperBrain

This comment has been minimized.

Copy link
Member

HyperBrain commented Oct 17, 2017

Hi @josephleehunsaker ,

thanks for the PR (and reading my blog post 😄 ). The idea to run a separate lifecycle that can be hooked is really beneficial.
I think the approach to just "run" the webpack command is the wrong approach in this case. It would be better to declare a completely internal lifecycle as entrypoint and spawn that via plugin manager.

That offers a much better reusability of the internal steps like validation and does not invoke a complete command. I did such an implementation in the AWS deploy command which spawns it's internal lifecycle (aws:deploy:*) instead of executing a whole command.

Commands should not be run from a plugin (using "run") because they may introduce side effects special to that command.

A better solution would be to declare entrypoints webpack:validate, webpack:compile, webpack:packExternalModules and webpack:packModules and use pluginManager.spawn('....') to invoke their lifecycles. Then any plugin can hook wherever it wants to, may it be the validation, the compilation or the packaging (both levels). The public commands and hooks (webpack, before:....) will then only spawn the webpack lifecycles.

So the hookable lifecycle model would be:

-> webpack:validate:validate
-> webpack:compile:compile
-> webpack:package:packExternalModules
-> webpack:package:packModules

The webpack plugin hooks will then just spawn them like this:

-> webpack
  -> webpack:validate
  -> webpack:compile
  -> webpack:package

-> before:deploy:createDeploymentArtifacts
  -> webpack:validate
  -> webpack:compile
  -> webpack:package

-> before:deploy:function:packageFunction
  -> webpack:validate
  -> webpack:compile
  -> webpack:package

A 3rd party plugin can then hook any of these, and additionally the lifecycle events themselves are extensible, so that e.g. the webpack:package lifecycle could easily get new events if needed.
The last benefit is, that the webpack command will be independent and could even be dropped or changed, without changing anything.

@HyperBrain

This comment has been minimized.

Copy link
Member

HyperBrain commented Oct 17, 2017

If you have "enable edits by maintainers" enabled, I will change the PR accordingly - should be straight forward (and make the unit tests test the new behavior).

@josephleehunsaker

This comment has been minimized.

Copy link
Contributor Author

josephleehunsaker commented Oct 17, 2017

Terrific, thx. I would appreciate it if you could get it working just right :)

I am still learning webpack plugins and serverless plugins.. so I did just enough to get the job done on my end.

I believe "enable edits by maintainers" is enabled. Let me know if you are unable to change the PR.

@HyperBrain HyperBrain added this to the 4.0.0 milestone Oct 23, 2017

@HyperBrain

This comment has been minimized.

Copy link
Member

HyperBrain commented Oct 23, 2017

@josephleehunsaker You should now be able to hook before:webpack:validate:validate or after:webpack:validate:validate. Your hook will be triggered on all occurences where the webpack plugin calls its validation (e.g. webpack command, sls package/deploy, etc).

@HyperBrain HyperBrain merged commit 5c9f14d into serverless-heaven:master Oct 23, 2017

2 checks passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
coverage/coveralls Coverage increased (+0.06%) to 90.948%
Details
@HyperBrain

This comment has been minimized.

Copy link
Member

HyperBrain commented Oct 23, 2017

Can you give it a try with serverless-heaven/serverless-webpack#master and check if the standard deploy stuff still works?

@HyperBrain

This comment has been minimized.

Copy link
Member

HyperBrain commented Oct 31, 2017

Released with serverless-webpack@4.0.0

@josephleehunsaker

This comment has been minimized.

Copy link
Contributor Author

josephleehunsaker commented Nov 9, 2017

Thank you so much!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment