-
Notifications
You must be signed in to change notification settings - Fork 1.6k
Builds
We have various targets that must be run to build the site. Primarily web.dev is based on 11ty, but it has various steps around that to correctly build.
You can build a whole production build (one-off) with ELEVENTY_ENV=prod npm run build (or remove the env var for a faster/debug build).
You can run a development server with npm run dev, which will restart and rebuild on changes.
We take a reasonably standard approach to 11ty, with a large number of helper filters and shortcodes available to content authors.
Its config file is in the usual place.
11ty can be run on its own via eleventy and will build a static version of the site (but it won't have e.g. styles or JS available at all, so you should run npm run dev).
Media shortcodes like {% Img %} and {% Video %} are eventually provided by the webdev-infra project.
Every file under "src/lib" is code that is included on the front-end. These files are written in ESM, as opposed to 11ty which is all in CJS (this requirement seems unlikely to change—11ty uses various hacks around CJS to work).
We use Rollup plus plugins to build this JS, which results in multiple entrypoints. See the Rollup config file.
Each JS file under src/lib/pages is considered an entrypoint to Rollup. This generates a graph of files, e.g., if two entrypoints use the same code, they'll depend on a common shared bundle.
Pages can load entrypoints by adding a line to the pageScripts part of their front-matter.
See the measure page here.
Rollup defines two "virtual imports", accessible at webdev_analytics and webdev_config (see the config file).
These aren't real packages, but just contain a JSON blob of various environment and other config things, accessible by any client-side code.
This includes e.g., the correct Firebase config for the build.
We use the postcss plugin, which if it sees SCSS/CSS being imported into a JS file, will automagically build that CSS and insert it into the page's <head>.
This is used by our web components to add their global styles.
Gulp performs some massaging of our files so they can be correctly used by a production or dev build of the site. See its config file here.
It has a number of tasks, mostly to do with copying assets, but also compiles the global SCSS and writes the "built at" version token (which ends up at https://web.dev/version).