As you work on CodePen, your Pens are constantly running through the CodePen Compiler. The CodePen Compiler creates and runs a build process that is composed of a series of Blocks. Blocks are technologies that process code. Most Blocks are things you’ve heard of. For example, Sass, the popular CSS processor, is a Block (along with all the other popular CSS processors). Blocks are designed to work together, so you can add as many Blocks as you like to a Pen and CodePen will ensure they work together.

You can see the current build status in the Blocks panel in the Editor. The Blocks panel does double duty. It shows you all the Blocks added to that Pen, and it shows you the last time it ran the build process through those Blocks and what happened.

Running Builds

Builds are automatically run for you. They happen when you stop typing for a second. The CodePen Compiler creates a build plan and then runs it for you.

✨ While it may seem fast and simple, CodePen is doing a lot for you to make this build happen. For example, the CodePen Compiler parses all the files in your Pen to understand how they are connected, what depends on what, and links to what, and what technologies are needed to do the processing. This deep understanding of your code is what allows CodePen to help you while staying out of your way.

You can’t control the build plan yourself, it’s automatically created and run for you. If you think the build plan is incorrect (like something processing out of order) please contact support.

Build Status

Hopefully, your build will run with no problems at all! But builds can fail for a number of reasons. Just a missing semicolon in your SCSS file, for example, can cause the Sass block to error and your build to fail. But never fear, CodePen will help you see what went wrong with Diagnostics. They will help show you what’s wrong and where, and hopefully you can fix it quickly and run a fresh build.

Build Status Block Categories

When you view the Blocks panel and see the Build Status chart, you’ll see the blocks organized

Format Blocks

Formatting Blocks are Blocks that format your code, like Prettier or JS Beautify. They are technically a part of your build processes, but they run as one-off jobs, as in, if formatting needs to be done on your code, it will be done, updating your source files, then a new build will trigger, using your formatted code as the real source.

You are allowed to use multiple formatting Blocks on a Pen, but only one formatting Block will run on any particular file type as determined by extension (e.g. .html or .css, for example). The way this is determined is by the order the Blocks are added to your Pen. Say you’ve added a formatting Block that processes .apple, .orange and .banana, then you add a new formatting block that supports .apple and .pear, that new formatting block will take over on processing .apple, leaving the original formatting block to continue formatting .orange and .banana.

Lint Blocks

Blocks in the lint category do not change your code, they only warn you about potential problems. A block like Stylelint, for example, will tell you (with the default-but-changable configuration) if you’ve unnecessarily repeated a style declaration, or left a uselessly empty ruleset.

A lint block never prevents a build from succeeding. Only warning Diagnostics will be generated.

Process Blocks

Process Blocks take your existing files and process them to create new files. A classic example is the Sass block which will take .scss or .sass files and produce a .css file.

A Process Block may produce less files than it starts with, for example, a .scss file with lots of small included files that get processed together. Or the Block may produce more files than it starts with, like a single .ts (TypeScript) file producing a .js file output and a .d.ts types file.

Base Blocks

Base Blocks are similar to Process Blocks in that they produce new files, but Pens are limited to one Base Blocks. These tend to be site-building tools like Next.js or Eleventy, where the processing tends to happen over the entire file system and using more than one would be illogical.

The Auto-Updating Preview Setting

It’s sometimes beneficial for the preview not to update when a build runs. This might be because an animation runs automatically that you don’t want to restart, or you don’t want the scrolling or form elements to reset. Turning off the Auto-Updating Preview Setting will ensure the preview doesn’t refresh until you press the Refresh Preview button.

The Auto-Updating Preview setting is available in Pen Settings → Behavior & Processing or the dropdown menu at the top of the Preview area.

Minimizing Errors

Builds can throw errors for a variety of reasons, like syntax errors in code or configuration problems. Because builds run when you stop typing, you might be in the middle of a thought, and the syntax error is expected. By default, errors show up in the preview area, but you can close the errors there with the close button and they will stay minimized until you choose to open them again. The preview shows the last successful build.