feat: Integrate Bootstrap 5.3.3 via npm and Hugo modules #173
Conversation
- Add Bootstrap 5.3.3 as a npm dependency - Configure Hugo module mount for Bootstrap JS - Update script path for Bootstrap bundle in base-foot partial - Remove pre-bundled Bootstrap JS and source map files from static directory
- Remove submodule-related commands and status checks - Refactor workflow to use Hugo modules for theme management - Update commit messages to reflect module-based approach - Streamline PR creation and update process
- Set specific Hugo version (0.141.0) for consistent builds - Use peaceiris/actions-hugo action to setup Hugo - Ensure extended Hugo version is used for theme compatibility
- Add conditional check to prevent re-initializing existing go.mod - Ensure Hugo module initialization only occurs when needed - Maintain consistent module management approach
- Mount Bootstrap bundle directly to vendor directory - Use Hugo resources for fingerprinting and optimization - Update base-foot partial to leverage Hugo's resource management
- Integrate npm-run-all to enable parallel and sequential script running - Update package.json scripts to use npm-run-all for build and test workflows - Add test script that runs build and parallel test commands - Enhance development and testing process with more flexible script execution
- Add conditional check to prevent processing empty CSS resources - Wrap CSS resource retrieval with `with` to handle potential nil resources - Ensure CSS bundle is only generated when resources are available
- Replace static hugo.toml generation with sed command - Use in-place modification to update module branch dynamically - Maintain workflow's ability to point to specific theme branch
- Modify workflow trigger to run after successful test-example-site workflow - Add conditional check to ensure workflow only runs on test success - Improve workflow reliability and dependency management
- Remove specific branch trigger for test workflow - Add new job to trigger demo update workflow after successful tests - Use GitHub Actions script to dispatch update-demo-pr-external workflow - Improve workflow automation and dependency management
- Update workflow to get specific theme module commit instead of branch - Remove hugo.toml modification step - Adjust commit and PR title to reference specific commit hash - Improve precision of theme module update process
- Add conditional check to install Playwright browsers only when cache is not hit - Rename cache step to more accurately describe cached resource - Improve workflow efficiency by avoiding redundant browser installations
- Add dynamic ref selection for workflow dispatch - Support both pull request and direct commit contexts - Log the selected reference for clarity - Enhance flexibility of demo update workflow trigger
- Remove external workflow trigger for demo update - Update PR demo site workflow to directly trigger on pull requests - Modify theme module update process to use branch instead of specific commit - Streamline workflow configuration and improve PR preview mechanism
- Remove the condition that checks for successful test workflow - Simplify demo site update workflow trigger configuration - Improve workflow flexibility and direct triggering
- Switch workflow trigger to run after successful test workflow - Modify theme module update to use specific commit instead of branch - Remove hugo.toml modification step - Update Hugo version and improve workflow reliability
- Change workflow trigger from workflow_run to pull_request - Update Hugo version to 0.141.0 - Simplify workflow configuration for direct PR-based demo site updates
- Add fallback to git rev-parse HEAD when GITHUB_SHA is not set - Ensure reliable commit reference selection in workflow - Enhance workflow's ability to handle different GitHub Actions contexts
|
What I want to achieve are the least steps needed from the theme using site, the "cleanest" option, so to say. At the moment I have a working solution: A change like that would come with theme guidelines on how to do it, as in: But I'm also exploring what options are there to vendor the dependencies (source: https://discourse.gohugo.io/t/mounting-node-modules-from-hugo-module/31629). One option could be to vendor the |
…theme # Conflicts: # UPGRADING.md
- Include Playwright, TypeScript, and PostCSS development dependencies - Set up configuration for build and testing tools Seen at https://discourse.gohugo.io/t/how-should-i-use-package-hugo-json/43055, https://notes.nicholasnooney.com/notes/hugo/working-with-modules/
- Remove Playwright and TypeScript dev dependencies - Add Bootstrap 5.3.3 as a project dependency - Retain PostCSS and related build tools
- Improve Hugo module installation guide with detailed steps - Add collapsible sections for better readability - Clarify theme installation methods and prerequisites - Update Hugo version and dependency information
Improve the welcome message by fixing a grammatical error in the showcase title translation
|
In the end I got quite some inspiration from @schnerring 's https://github.com/schnerring/hugo-theme-gruvbox/tree/main?tab=readme-ov-file, and used Added it to the readme/instructions too. As discussed with @Luosua in #177, there are some usability issues of hugo modules vs git submodules ( |
|
One idea just came up into my mind. I'm actually sleeping, but I woke upwith it. GitHub has plenty of options to create build processes. One could provide an additional artifact that contains the Bootstrap dependencies as has been before. That allows people to use the theme without relying on modules. So basically, the idea is to provide different release artifacts. |
that's a good idea - the theme already has some CI/CD to automate releases, it'd be about extending it. |
Implements #172 (spillover/tech debt from #167)
package.hugo.jsonto allow packing of the dependencies to siteexampleSitedirectly and running a build)The theme loads alright without the bootstrap files embedded into the theme
To review:
npm iwhen setting up the theme? can it be automated?)adritian-demo(after the change to modules)