Add automated frontend build to v2.0dev #77
Conversation
Our content type actually is `text/html`, as set by the ESP32 static content server.
Use [`inline-source` npm package](https://www.npmjs.com/package/inline-source), run `index.html` through it in order to inline all the scripts and styles we wish to bundle. Extract the `dronebridge.css` into separate file to have it enjoy the same automation. Run `npm run build` in `frontend_src` in order to build into `../frontend` (considered building into `build/frontend` as well).
I tested the frontend out on this one (without a real FC yet) and it appears to work, no styling changes or JS breakage.
|
Looks great, thank you!
I agree. If we can add the npm as part of the cmake process move it to the build directory for now (adjust cmake here to set new relative path). We can document the build process in the readme as part of |
I think it does! Let me take a stab at it, thanks for linking these resources. |
Move `frontend_src` to `frontend`. Add a dependency between `spiffs_create_partition_image` and frontend build. Extract the build output directory to a variable in the `package.json` script.
|
@seeul8er I think ^ should do it. It rebuilds the frontend on every build, but the build is so quick I don't think it should matter. |
|
Let's merge! Thank you so much! |
Use
inline-sourcenpm package, runindex.htmlthrough it in order to inline all the scripts and styles we wish to bundle.Extract the
dronebridge.cssinto separate file to have it enjoy the same automation.Run
npm run buildinfrontend_srcin order to build into../frontend(considered building intobuild/frontendas well).Remove unused
meta-setcontent-typeheader, as we set one in the ESP32 static server.I tested the frontend out on this one (without a real FC yet) and it appears to work, no styling changes or JS breakage.
Pending questions: now that
frontenddirectory is a build artifact, should we remove it from the repository, and if so, renamefrontend_srcinto justfrontend?Happy to tweak anything here to your liking :)