Best Practices for building Angular Schematics

Tips and tricks to help make building schematics easier

Image for post
Image for post
Photo by rawpixel on Unsplash

Use a sandbox project to test your schematics’ functionality as you develop

Testing the functionality of your schematics to make sure they behave the way you expect can be tricky. It usually involves having to link your project to another Angular application and then going back and resetting things after you run your schematics before you try again. This can be cumbersome and much more time than I would like. What if I told you it didn’t have to be that way?

  1. Update these two scripts to the sandbox’s package.json

Type your schemas

Schemas are great. They allow you to define what options your schematic is expecting and use dialogs to gather information from the user instead of forcing the user to remember various flags for your schematic. After I create a schema.json file for my schematics I find it helpful to create an interface that represents that schematic's options.

Organize your project by schematic

This may seem like a no-brainer, even the example project generated by the Schematics CLI when you run schematics schematic organizes files like this (note: see Brian Love’s tutorial if you need a refresher regarding the Schematics CLI). It really is the best way to organize your schematics and adhering to this will save you a lot of headache down the road. For example, if my project had three different schematics (let's call them schematic-a, schematic-b, and schematic-c) you should organize your project like so:

Create helper schematics

The great thing about schematics is that they can call other schematics! This means you can split up your functionality among multiple schematics and make them more modular. For example, if I had a schematic that installed some libraries then modified something in the file tree I would create one schematic to handle the installation of the dependencies, one to deal with the file system interactions, and a third to serve as the main schematic that chains the previous two.

Use the files property of package.json to only publish what you want

As your project grows and becomes more complex you might have more files and directories added to it. This can be great and ease our lives as developers but a lot of that other stuff we use for developing our schematics should not be packaged with the schematics when we publish to npm for others to use (our fancy new sandbox for example). Those files will never be used by end users and can bloat the footprint of our schematics package.

Wrap up

Schematics are very exciting and very powerful. There are a lot of techniques that can help to make the building of schematics a lot less difficult. Now you have a few more tools in your schematics toolbox to make sure you can build maintainable and highly performing schematics for your projects. Go forth and see what you can create!

ngconf

The World’s Best Angular Conference

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch

Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore

Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store