In today’s episode, I’ll be telling you why you should “use the source” like Luke Skywalker used the force.
This is a timely episode. My wife and I just recently got a Disney+ subscription and watched the entire Skywalker Saga from start to finish.
It was my wife’s first time watching the series…I know 😱
Since watching the series, the talk of the house has been full of Star Wars references such as “use the force.”
While my wife and I have been saying “use the force,” I was reminded of the value of telling myself to “use the source.”
dark side. It’s cold and mysterious, and if you expand your
node_modules directory, you might get blasted by Emperor
There is some good reason for that. After all, there can be a lot of packages
Using the source is a great way to find out “why” a shareable package was created in the first place.
A package is shared when it solves a common problem.
README often provides a good sense as to what the
problem is and how the package solves it.
Digging into the source code reveals “how” the problem was solved.
You may not need to write all the code out yourself to solve the problem (since you can use the shared package), but you may need to peak into the source code to understand how it solves the problem.
As you explore how packages solve problems, you will gather ideas of how you can take bits and pieces of the solutions and apply them to unique problems that you come across as a professional developer.
Think of a shared package as a completed Lego set and the source code as the Lego.
For example, as part of my series on design tokens, I wrote an article on using a package called Style Dictionary to generate HSL color shades.
Style Dictionary is a shared package that can take a JSON file representing design specifications (also called design tokens) and transform them into a platform deliverable.
My article was on leveraging Style Dictionary to transform a JSON file with design specifications of “primary,” “secondary,” and “error” colors and exporting those colors, along with a range of shades, as CSS variables.
Before, Style Dictionary seemed like magic. I ran the CLI tool and it transformed a JSON file into CSS variables after I sprinkled some settings in a config file.
After getting stuck on how to generate shades from a single color, I dove into the source code.
When I was not able to find a pre-defined way to use Style Dictionary to
transform a single color into shades, I was able to go straight to the
tinycolor library to solve the problem.
If I only knew about the Lego set, I would never have known about the value of the Lego. If I never looked into the source code, I would have never learned about how I could extract a portion of the code to solve a different problem.
Use the source.
I’ll conclude this episode with a final tip as well as a challenge.
My tip is to start at the entry file of the source code and work your way through it. It can be confusing if you pick a random file to examine. However, starting from the beginning of the problem and working your way through the solution will help demystify the source. Treat it like a code review, read comments, and parse out what is relevant versus irrelevant.
My challenge is to use the source this week on any codebase that you touch.