Webmasters Gallery

Netlify just dropped a new thing: Build Plugins. (It’s in beta, so you have to request access for now.) Here’s my crack at explaining it, which is heavily informed from David Well’s announcement video.

You might think of Netlify as that service that makes it easy to sling up some static files from a repo and have a production site super fast. You aren’t wrong. But let’s step back and look at that. Netlify thinks about itself as a platform in three tiers:

1. Netlify Build
2. Netlify Dev
3. Netlify Edge

Most of the stuff that Netlify does falls into those buckets. Connecting your Git repo and letting Netlify build and deploy the site? That’s Build. Using Netlify’s CLI to spin up the local dev environment and do stuff like test your local functions? That’s Dev. The beefed-up CDN that actually runs our production sites? That’s Edge. See the product page for that breakdown.

So even if you’re just slapping up some files that come out of a static site generator, you’re still likely taking advantage of all these layers. Build is taking care of the Git connection and possibly running a npm run build or something. You might run netlify dev locally to run your local dev server. And the live site is handled by Edge.

With this new Build Plugins release, Netlify is opening up access to how Build works. No longer is it just “connect to repo and run this command when the build runs.” There is actually a whole lifecycle of things that happen during a build. This is how David described that lifecycle:

1. Build Starts
2. Cache is fetched
3. Dependencies are installed
4. Build commands are run
5. Serverless Functions are built
6. Cache is saved
7. Deployment
8. Post processing

What if you could hook into those lifecycle events and run your own code alongside them? That’s the whole idea with Build Plugins. In fact, those lifecycle events are literally event hooks. Sarah Drasner listed them out with their official names in her intro blog post:

• init: when the build starts
• getCache: fetch the last build’s cache
• install: when the project’s dependencies are installing
• preBuild: runs directly before building the functions and running the build commands
• functionsBuild: runs when the serverless functions are building, if they exist on the site
• build: when the build commands are executing
• package: package it to be deployed
• preDeploy: runs before the built package is deployed
• saveCache: save cached assets
• finally: build finished, site deployed ?

To use these hooks and run your own code during the build, you write a plugin (in Node JavaScript) and chuck it in a plugins folder at like ./plugins/myPlugin/index.js

function netlifyPlugin(conf) {
  return {
    // Hook into lifecycle
    finally: () => {
      console.log("Finished!")
    }
  }
}

module.exports = netlifyPlugin

…and adjust your Netlify config (file) to point to it. You’re best off reading Sarah’s post for the whole low-down and example.

Finished my first @Netlify build plugin. Now all I need is my pre-beta access to run a test.

KISS #jamstackconf pic.twitter.com/VIAnal1SpD

— Tony Alves (@3_Alves) October 17, 2019

OK. What’s the point?

This is the crucial part, right? Kind of the only thing that matters. Having control is great and all, but it only matters if it’s actually useful. So now that we can hook into parts of the build process on the platform itself, what can we make it do that makes our lives and sites better?

Here’s some ideas I’ve gathered so far.

Sitemaps

David demoed having the build process build a sitemap. Sitemaps are great (for SEO), but I definitely don’t need to be wasting time building them locally very often and they don’t really need to be in my repo. Let the platform do it and put the file live as “a build artifact.” You can do this for everything (e.g. my local build process needs to compile CSS and such, so I can actually work locally), but if production needs files that local doesn’t, it’s a good fit.

Notifications

Sarah demoed a plugin that hits a Twilio API to send a text message when a build completes. I do this same kind of thing having Buddy send a Slack message when this site’s deployment is done. You can imagine how team communication can be facilitated by programmatic messaging like this.

Performance monitoring

Build time is a great time to get performance metrics. Netlify says they are working on a plugin to track your Lighthouse score between deployments. Why not run your SpeedCurve CLI thing or Build Tracker CLI there to see if you’ve broken your performance budget?

Performance expert @tkadlec wrote a Netlify Build Plugin for @SpeedCurve!
In this post, he breaks down how he our new private beta feature to create some perf tests for your site. Great writeup! https://t.co/aYU9NmosQQ pic.twitter.com/FnX6KgeLRG

— Netlify (@Netlify) October 22, 2019

Optimizations

Why not use the build time to run all your image optimizations? Image Optim has an API you could hit. SVGO works on the command line and Netlify says they are working on that plugin already. I’d think some of this you’d want to run in your local build process (e.g. drop image in folder, Gulp is watching, image gets optimized) but remember you can run netlify dev locally which will run your build steps locally, and you could also organize your Gulp such that the code that does image optimization can build part of a watch process or called explicitly during a build.

Images are a fantastic target for optimzation, but just about any resource can be optimized in some way!

I built a @Netlify build plugin to run subfont on your website. Seems like I don’t have access to the build plugins myself yet, so I’d appreciate it if someone would try it out and give me feedback.https://t.co/PrnL65JSwb

— Peter Müller (@_munter_) October 18, 2019

Bailing out a problematic builds

If your build process fails, Netlify already won’t deploy it. Clearly useful. But now you could trigger that failure yourself. What if that performance monitoring didn’t just report on what is happening, but literally killed the build if a budget wasn’t met? All you have to do is throw an error or process.exit, I hear.

Even more baller, how about fail a build on an accessibility regression? Netlify is working on an Axe plugin for audits.

Clearly you could bail if your unit tests (e.g. Jest) fail, or your end-to-end tests (e.g. Cypress) fail, meaning you could watch for 404’s and all sorts of user-facing problems and prevent problematic deploys at all.

Use that build

Netlify is clearly all-in on this JAMstack concept. Some of it is pretty obvious. Chuck some static files on a killer CDN and the site has a wonderfully fast foundation. Some of it is less obvious. If you need server-powered code still, you still have it in the form of cloud functions, which are probably more powerful than most people realize. Some of it requires you to think about your site in a new way, like the fact that pre-building markup is not an all-or-nothing choice. You can build as much as you can, and leave client-side work to do things that are more practical for the client-side to do (e.g. personalized information). If you start thinking of your build process as this powerful and flexible tool to offload as much work as possible to, that’s a great place to start.

The post Netlify Build Plugins Announcement appeared first on CSS-Tricks.