Replaces the multi-process bundle approach with webpack-dev-middleware
This is a common annoyance for students and shows up as this sequence while debugging:
1 Student makes change to front-end code and save file.
2 webpackstarts bundling
3 Student reloads web browser, loading stale bundle.js. Student debugs against old code, possibly drawing incorrect conclusions about whether their changes were correct.
4 webpackfinishes bundling
5 Student goes back to editor and makes more changes.
6 Cycle repeats.
I've regularly stepped into Sr Phase help tickets where students were in this cycle and did not realize it, having wasted quite a bit of time and having lost a lot of confidence in their sanity.
Using webpack-dev-middleware would increase a delay and the cycle would go like this:
1 Student makes change to front-end code and save file.
2 webpackstarts bundling
3 Student reloads web browser, server blocks until bundle is complete, fresh bundle is served.
This PR includes an explanatory comment for students.
// This middleware will match requests to GET /bundle.js
// An advantage to using this middleware is if webpack is
// in the middle of a compilation the request will not
// return content until the fresh bundle is availble.
//
// In production, the bundle will be generated and stored in the
// public/ directory.
Replaces the multi-process bundle approach with
webpack-dev-middleware
This is a common annoyance for students and shows up as this sequence while debugging:
webpack
starts bundlingbundle.js
. Student debugs against old code, possibly drawing incorrect conclusions about whether their changes were correct.webpack
finishes bundlingI've regularly stepped into Sr Phase help tickets where students were in this cycle and did not realize it, having wasted quite a bit of time and having lost a lot of confidence in their sanity.
Using
webpack-dev-middleware
would increase a delay and the cycle would go like this:webpack
starts bundlingThis PR includes an explanatory comment for students.