How Shadowing Works
Shadowing is a powerful feature that allows theme users to override components,
objects, and anything else in a theme’s
Note This is a technical deep dive into how Shadowing works. If you’d like to learn about what Shadowing is, see the What is Component Shadowing? blog post.
Shadowing works by using a webpack resolver plugin
that maps themes in a
gatsby-config.js to possible shadowed files. This gets
especially mind melty because themes can add parent themes to a configuration so you
need to be able to walk the composition of themes to determine the “last shadow”
since the last shadowed theme file wins in the algorithm.
It’s important to begin discussing how the composition of themes works. An
end user of a theme can configure any number of themes. Each of these
themes are considered sibling themes. Here is a
configures two sibling themes:
Both of the themes above (blog and portfolio) can install and configure any other theme so you end up with a tree of themes which we call a theme composition.
The theme composition itself has a few properties:
- the last theme wins
- a theme that uses another theme is the child theme
- a theme that is used by another theme is the parent theme
- theme trees are flattened during resolution
These characteristics are used in the component shadowing algorithm
to decide which component to render. So, for example, if
gatsby-theme-parent as a parent theme it results in the following themes
This means that
gatsby-theme-tomato-portfolio receives priority for
component resolution, because it is last in the array.
Component shadowing is a bit meta because it is implemented as an internal Gatsby plugin that applies a webpack plugin which modifies how module resolution happens for files that are shadowed.
The plugin consists of a
gatsby-node.js and the webpack plugin code.
gatsby-node file is pretty straightforward:
We first check for themes in the redux store. This is for
backwards-compatibility since themes are now merged with
plugins. If the
themes key was used in the user’s
gatsby-config.js those are passed to the shadowing resolver
plugin. Otherwise, the flattened plugin list is passed.
The webpack plugin itself has a constructor and an apply function which webpack calls as part of module resolution. We tie into the “relative” hook in the pipeline.
request contains the path of the file which we want to use to find
potential matches in themes.
Which is defined on the class:
This is run for all files in the site bundle and checks for potential matches.
So, if a request is
gatsby-theme-tomato is installed on the site, we’ll return
We perform this match so that we can determine the theme that is being required from so we can check for shadowed files in the user’s site or other themes to match against. We also make sure the matched themes are unique because two themes can bring in the same theme to the theme composition. When that’s the case we won’t worry about them being different. Though, it is important to note that when performing resolution to build the site, the last theme added will always win.
Next, we check to make sure that if there is more than one matching theme there
is some sort of ambiguity and we should return an error. This can happen if there’s
a path like
in the project.
If there are no theme matches we return the invoked callback because there’s nothing more to do, time to let webpack continue on it’s way with module resolution.
Now, if we still haven’t returned the callback or thrown an error (due to ambiguity) it means we
have a file being required from a theme. The file being required will look something
/some/path/my-site/gatsby-theme-tomato/src/box and so the first thing we
want to do is get the relative path for the file within the theme’s
So, with the example path above we’ll end up with
/box. This can then be used to
see if the user’s site or any other themes are shadowing the file.
Since a file from a theme is being required we need to figure out which path should
be resolved for the requested component. We do this by calling
which uses the theming algorithm to attempt to find a shadowed component. If nothing
is found we return the original request which points at the original theme’s
doResolve on the resolver which specifies the shadowed component path if
one is found, otherwise the original request. This is what tells webpack to resolve
and bundle that particular file.
When looking for a component we perform a search that occurs in two locations:
- user’s project
In order to ensure that the user’s project always takes precedence in terms of shadowing
it’s prepended to the theme list when attempting to resolve the component. This ensures that
my-site/src/gatsby-theme-tomato/box.js will take priority over any other theme that
might want to shadow the same component.
As discussed before, themes are flattened into a list and then all possible shadow paths are constructed to match against. When concatenating with the user’s project it’s important to note again that the themes array is reversed. This is how we ensure that “the last theme wins” when resolving a shadowed file. We walk the list for matches from start to finish.
Additionally, the original theme is removed because that’s the default behavior of webpack so we don’t need to resolve a theme to itself.
The shadowing algorithm can be boiled down the following function that’s roughly 20 lines of code:
This is where things begin to get a bit whacky. In addition to overriding a file, we want it to be possible to import the very component you’re shadowing so that you can wrap it or even add props.
This is the first case we’ll handle when attempting to resolve the file.
In order to do this we need to leverage the issuer of the request. This points to
the file that the request came from. This means it refers to where the
The request refers to what the import points to.
This is implemented by another method on the plugin’s class which we call
requestPathIsIssuerShadowPath which has the following method signature:
requestPathIsIssuerShadowPath checks all possible directories for shadowing and
then returns whether the issuer’s path is found. Let’s first take a look at the
code and then unpack what’s happening here.
In the above code block
This constructs the shadowable files for
gatsby-theme-tomato’s Box component.
Then, we join the component path and end up with:
We then know that if the issuer matches one of these components that it’s being extended. This means that a shadowed component is extending the same component from its parent.
When this happens, we return the next path, so here the original location of the theme:
This means that when our shadowed file imports Box from a shadowed file we return the original box component defined in the theme.
As a result, the following will work as we expect:
Now, all usages of the Box in
gatsby-theme-tomato will be also wrapped in a purple
If a theme sets
the issuer will be null. As such we need to first check that the
is present before we attempt to resolve the shadowed component.
It’s important to note that we don’t recommend appending to the modules list in themes. Though, if you do, we will make sure we don’t arbitrarily error.
Shadowing uses a predictable algorithm that leverages webpack to dynamically
change module resolution based on a
gatsby-config and theme composition.
The last theme will take precedence in the shadowing algorithm, and the
src directory is always take into account first.
Edit this page on GitHub