Closed Lenni009 closed 1 year ago
index.html
is automated in the build pipeline, as well as a few others ๐
. I like having them in git because it is easier to confirm the changes are what you are expecting them to be ๐
. It would probably be better to untrack all the generated files from git ๐ค. Especially if someone makes changes to one of the generated files expecting it to change the website
I tried to group the scripts in the package.json so that it was more clear what each one does, I guess I didn't succeed ๐
Especially if someone makes changes to one of the generated files expecting it to change the website
That's exactly my concern.
I myself would've approached this whole project and its building differently:
Pros: More developer friendly
Cons: Less search engine friendly
At least that's how I see it. But you went with handlebars (no idea what that is tbh ๐ ), so I trust you to know what you're doing haha. Also the site looks awesome btw!
I mean in theory you could even do something like "build HTML dynamically during dev, build HTML statically during build". It'd be some work, but I think it would be possible. I'm not suggesting to implement something like that here, it would basically be the same as rewriting everything again. Maybe for the next iteration of the page
Yeah, I will untrack the generated files ๐ . I am pretty much using the exact same approach, just instead of Vite, using Handlebar templates and instead of doing it at runtime, the solution does it at compile time so that there is almost no JS on the front-end.
Handlebar is pretty straight forward, it is just a template system, kinid of like doing string interpolation but with a few built-in helpers and the ability to create your own custom helpers ๐. You can also run HandlebarJS on the page and compile templates at runtime, but you miss out on the SEO advantages. It would be cool for rendering content from APIs at runtime, haven't needed it yet and I would probably make a webcomponent for that ๐ค
The npm run dev
command has watchers for changes in different file types, so if you edit a .scss file for example, it will run the command to generate the .css files and the page will reload automatically. And the same for the template (.hbs) files. One problem I have had so far is that the service-worker caches the site too hard on local, so I still have to refresh the page manually ๐. I think I can tell the live-server to not serve that file, then the hot reload would work again ๐
There's vite-plugin-handlebars, not sure how well that scales though.
What do you need the service worker for?
That will work and probably very well๐. I have used the webpack plugin for handlebars. The plugins work well, but I decided to not go down the route of webpack, vite or any other bundler because I like handling the files myself... Maybe I like the punishment ๐. Vite also has the built in live-server, so it could replace a some of the npm scripts ๐ค
The service-worker is only there for SEO, it improves the Lighthouse scores ๐. It is also part of making the site a PWA, so people could "install" the app to their phone... Although I don't know who would want to do that ๐
Everything for the perfect Lighthouse score!
In #4, it looks like the
index.html
file has changed to have all the new data from theprojects.json
file. This means that this was generated by a human as far as I know, otherwise it would not show up in the PR.In my opinion, this should be done by the CI/CD pipeline during the build process, and automatically by the build tool during dev. No human interaction should be required to get a change from
projects.json
toindex.html
. Is there a specific reason this is not automated?I looked at the
package.json
and honestly have no idea what all the scripts do. But I'm sure there must be a way to automatically build all the projects.json stuff in the CI/CD instead of having to do it on a local machine. Removing this human dependency can also result in less confusion and less issues for contributors.