[shazron]

This is for the situation where if you have a file watcher process, and you need to rebuild an action due to a webpack-config.js change.

Closes #35

How Has This Been Tested?

1. Add a actions/webpack-config.js file, exporting a CommonJS module as a webpack config
2. Run DEBUG=@adobe/aio-lib-runtime:action-builder:debug aio app run
3. See the log of the web pack config being loaded
4. Wait until the 2 urls of your deployed application is logged
5. Edit actions/webpack-config.js with a new entry/delete an entry
6. See the log of the web pack config being loaded, it should be different

npm test

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• I have signed the Adobe Open Source CLA.
• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• All new and existing tests passed.

[codecov]

Codecov Report

Merging #33 (fff8d5d) into master (9ddef2d) will not change coverage.
The diff coverage is 100.00%.

@@            Coverage Diff            @@
##            master       #33   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files            9         9           
  Lines         1038      1043    +5     
  Branches       256       256           
=========================================
+ Hits          1038      1043    +5     

Impacted Files	Coverage Δ
src/build-actions.js	100.00% <100.00%> (ø)
src/utils.js	100.00% <100.00%> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 9ddef2d...fff8d5d. Read the comment docs.

[purplecabbage]

This looks good, but I worry that it leads to a greater maintenance workload for us.
Already, there is an issue where if an error is introduced in the webpack-config, hot reloading breaks, and no info is presented to the user, there are probably more latent issues we would uncover over time, where currently we do not have a responsibility to provide this functionality.

Also, I suspect the primary use cases for modifying webpack config while it is loading would be to add webpack plugins, which in turn need to be installed ... does that mean we also auto-install?

I am okay with merging this, I just want us to be sure we want the extra technical debt that may arise from adding it.

It would also be great if this feature came as a result of an ask from our users, personally I have very little understanding of how important this feature might be.