V2 -- Refactor index.html to be template-driven

[sthzg]

Currently we have a static index.html as entry point, which imposes a few limitations on more advanced use cases like server-side-rendering or modifying page parameters like asset paths (generator:#233), meta tags, or cache-hashes (generator:#217) at build-time.

To work around that, most other kits that I know work with some sort of templating language (template strings, EJS, React) to build the index.html dynamically. During that build we have full access to the bundle, including Webpack's stats object to access filenames, hashes, & co.

This would be a bigger update, but if you are interested in what it might look like I could setup a demo branch to discuss the architecture (and after that we could decide whether to follow that path or discard it).

[weblogixx]

@sthzg: Maybe we could use something like the html-webpack-plugin for this?

[sthzg]

👍 from what I read that could be a good fit for the requirement. Not quite sure about some aspects right now, I'll set it up locally to get a better idea and possibly push a branch to share what it would look like.

I will first start recreating the status quo and then try to see what would be necessary to modify the setup to accommodate for some different requirements, e.g. serving from sub-directories, multiple entry-points, server-side-rendering (not to include it into the project, but to look how painless certain integration paths become).

Checklist

Fundamentals (available in commit)

• runs with serve:dev
• runs with serve:dist
• * builds with npm run dist
• works with HMR
• passes all tests
• * builds correct asset-paths for running on non-root-directory **
• enables building with hashes for cache-busting

Critical Update Paths

Server Side Rendering

1. In order to lift a project to use SSR, users would add a server entry point, e.g. src/server.js.
2. Once that is done, users would update their template to compile to a file including an outer level of template strings (e.g. EJS). The server-rendering-pass may use these outer integration points to inject data required to render the initial state (from a database, external config, etc.).
3. Most likely users would add a universal routing lib like react-router to provide SSR for multiple routes within an application.
4. Users would update their Webpack config to also build a server bundle, which can be used in production to serve the project. If using any kind of CSS, there is also a need to configure extract-text-webpack-plugin (or some other solution to serve an asset for the styles built within an app).

---

• is there a way we can have automated tests on these requirements?
  ** except for V2 -- Update copying static files to copy-webpack-plugin #59, which is to be solved on a different branch

[sthzg]

@weblogixx the code in this branch now builds the index.html by using the html-webpack-plugin plugin. It passes all initial requirements that I could come up with (see checkboxes above).

There should also be a reasonable setup-path towards SSR. I outlined some of its building blocks above and plan to provide an example setup in a custom repo (when that works we could create the examples repository inside the organization and I can push it there).

[sthzg]

@weblogixx I'll report this one here, as it is a class of problems that would also be fixed with the approach from this branch.

Base.js:#176 sets publicPath to ./assets/, which breaks HMR in apps that use nested urls (because webpack tries to get the hot-update.json from the relative path, which does not exist).

As a first measure I'd propose pinning this value to /assets/. If you find time to checkout the changes in this branch I'd love to hear your feedback, if we want to go down the html-webpack-plugin route.

On a further note, I got react-hot-loader 3 beta now fully integrated into a generator app and it works fine (the 404 from this issue was the last obstacle between preserving redux state on hot updates 😄 )