Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What did you implement:
This PR consolidates all webpack plugin configuration settings into the new
custom.webpack
object. It effectively reduces cluttering of the serverless configuration and keeps all settings in one place.There is one breaking change with the configuration: If you have chosen to embed the webpack configuration into the serverless.yml (previously by defining
custom.webpack
as an object with the contents of a webpack config file) you have to move that tocustom.webpack.config
. In my opinion this way to configure webpack is very rare and mainly used as convenience method for the unit tests, as it does not allow for dynamic entry point resolution. This feature will be dropped in the future.The new configuration object has the following layout. If a property is omitted, it will default to the shown values:
All settings have just been moved, but semantically are exactly as before.
However, the old configuration keys continue to work, but will lead to a warning message to let people know that there is a better alternative for configuration now.
How did you implement it:
Use a new class to keep the configuration centralized. The class is initialized with the serverless custom object and will populate the settings from there (using the old semantics as fallback) and it will set reasonable defaults for anything that has not been set.
How can we verify it:
(1) Use an existing project as is. It should build as usual but show a warning.
(2) Adapt the configuration to use the new custom.webpack object. It should build as before.
Todos:
This PR introduced an expected drop in coverage, because it enables counting all files for coverage calculation. Previously only the tested ones were counted, but it was not obvious that there were untested files in the project.
Is this ready for review?: YES
Is it a breaking change?: YES (most likely not noticable)