Skip to content
Static site generator for knoxccl.org
HTML CSS JavaScript Shell
Branch: master
Clone or download
Permalink
Type Name Latest commit message Commit time
Failed to load latest commit information.
.github/workflows Added back the GitHub workflow file that I somehow lost in merge. Nov 15, 2019
files April 2018 newsletter Apr 9, 2018
flyers ServiceWorker changes for auto update and edit event announcement. Jan 30, 2019
src
static
.bootstraprc
.gitignore Moved static resources (i.e., ones that just get copied, not built), … Oct 25, 2019
README.md
package-lock.json
package.json Added GitHub menu item, restored CNAME. Nov 17, 2019
postcss.config.js
serve.sh Modified README, package.json and scripts to reflect new Amplify proc… Oct 27, 2019
webpack.config.js Exclude CNAME file from service worker precaching. Nov 15, 2019

README.md

Website for KnoxCCL

Files for the Citizens' Climate Lobby chapter site in Knoxville, TN. Visit the website at knoxccl.org.

Contributing

In general, work in feature branches in your own fork. When you are satisfied with your changes, create a pull request requesting to merge to master on https://github.com/dwvisser/knoxccl. When the pull request is accepted and merged, a new version of the website is automatically built and deployed on GitHub Pages infrastructure.

During development npm start, will keep a development server running which automatically reloads whenever changes are saved to the code and markup.

Development Guide

NPM and WebPack are used to bundle JavaScript and CSS libraries for the page. There are several npm run targets at your disposal:

  • clean - Removes the dist build folder and its contents.
  • develop - Build JS/CSS, including service-worker.js, with fewer optimizations for easier debugging.
  • build - Same as 'develop', but optimizing for deployment.
  • deploy - Prints a message about how to deploy. We're using AWS Amplify, pointed at the master branch on AWS CodeCommit, so any push to that branch results in a build in AWS, with deploy to the Amplify CDN upon successful build.
  • serve - Launches a local static content web server from the dist/ folder.

There are also these additional targets:

  • start - launches the WebPack dev server for local browsing/testing
  • watch - invokes webpack --watch for automatic rebuilding during editing

WARNING: npm run start and npm run watch aren't yet trustworthy. They don't appear to do the Workbox step. At present, I trust explicit npm run build or npm run develop followed by npm run serve, which is a more trustworthy test of the website as it will be served from AWS.

Source Structure

  • .booststraprc - Used to configure bootstrap-loader and include only what is needed by the site
  • .github/workflows/main.yml - Specifies the GitHub Actions workflow for building the site.
  • .gitignore - What files and folders Git should ignore.
  • package.json - NPM dependencies, see docs.npmjs.com
  • package-lock.json - describes exact dependency installations at a point in time; see docs.npmjs.com
  • postcss.config.js - seems to be necessary for CSS loader, initially set to empty config
  • README.md - this file
  • serve.sh - Helpful script for launching a static HTTP server for local testing
  • src/ - Files that are processed by WebPack build processes to generate output in dist/.
  • src/index.js - The WebPack entry point
  • static/ - Static content files that get copied, unmodified, by WebPack into dist.
  • webpack.config.js - Defines the WebPack build process

In addition, these folders are generated when building the site and are .gitignore'd:

  • dist/ - Where WebPack builds the working static site.
  • node_modules/ - Where all NPM dependences are placed

Local Build and Test

Before creating a pull request, make sure to create a production build, and serve it locally, as a final sanity check.

> npm run clean
> npm run build

The dist build folder will be removed by the first command, and re-built by the second command. You can then test the built version of the site with:

> npm run serve

The above command depends on having Python 3 installed (most Linux distributions do). If the site is ready for deployment, commit the changes to Git.

> git add […]
> git commit
> git push

Remember, while it is good to "backup" by pushing develop and feature branches, only pushes to the master branch on the main repository will result in the website being redeployed/updated.

To Publicize Significant Site Changes…

Make sure to update (or have someone else update) in these other places, too, where appropriate.

You can’t perform that action at this time.