Fixing 'Unexpected default error' when building Astro project

I was absolutely ecstatic to release my latest blog post about Auto-generating my PDF resume from my website so I was very bummed when I opened up Netlify to see this:

Peep the timestamps.. Yeah it was that kind of night

I kept getting a very cryptic error regarding a specific component in my project:

╭ adam@me-laptop:~/path/to/the/code (master)
╰ $ yarn build
yarn run v1.22.11
$ astro build
08:07:13 AM [content] Types generated 738ms
08:07:13 AM [build] output target: static
08:07:13 AM [build] Collecting build info...
08:07:13 AM [build] Completed in 1.33s.
08:07:13 AM [build] Building static entrypoints...
08:07:18 AM [build] Completed in 4.82s.

 building client
[astro:build] Transform failed with 1 error:
astro-entry:@components/CalendarComponent.astro:25:26: ERROR: Unexpected "default"
file: astro-entry:@components/CalendarComponent.astro:25:26

Unexpected "default"
23 |  Astro.self = $$CalendarComponent;
24 |
25 |  return $$render`export ${ default } from "@components/CalendarComponent.astro"`;
   |                            ^
26 |  }, 'astro-entry:@components/CalendarComponent.astro');
27 |  export default $$CalendarComponent;

transforming (36) node_modules/github-slugger/index.js error   Unexpected "default"
  File:
    astro-entry:@components/CalendarComponent.astro:25:26
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

This immediately struck me as odd for several reasons:

1. I had not changed this component in several days
2. I had not changed the single file that imported this component in several days
3. Why the hell was github-slugger failing to build on this particular file?
4. Related to the above, the failed transforming module was different every time I tried to build, with no discernable rhyme or reason.
   • transforming (36) node_modules/github-slugger/index.js error Unexpected "default"
   • transforming (13) node_modules/react/cjs/react-jsx-runtime.production.min.js error Unexpected "default"
   • transforming (12) node_modules/fuse.js/dist/fuse.esm.js error Unexpected "default"

So after squinting at code, hopelessly shuffling through google posts, and yes, even asking ChatGPT—I finally went nuclear.

There were only 5 commits between my last successful build and the first failed build. I decided I would remove each individual commit and re-try the build locally until I found the culprit!

Yep, I was feeling pretty proud of my debugging prowess, until… 6 commits reverted.. failed build.

7 commits reverted.. failed build.

8 commits revered.. failed build.

What in the world was going on?

So I did what all great developers do when they’re stuck. I went to bed. (Again, peep those timestamps. You probably should not expect great results when debugging at 1am.) After a good 6-hour nap, with plenty of “Did I try this?” dreams, I woke up with a genius idea: Just ask the Astro team on Discord.

In a shocking turn of events that surprised no one, an extremely helpful dev from the team was quickly able to isolate the problem in about 3 messages.

The Solution

The client:load directive can only be used on framework components. In other words, it can only be used on your React, Vue, Svelte, etc components—not on .astro components!

So I was using the <CalendarComponent /> like this:

---
import Shell from "@layouts/Shell.astro";
import CalendarComponent from "@components/CalendarComponent.astro";
import GoBackBtn from "@components/GoBackBtn.astro";
---

<Shell>
    <GoBackBtn />
    <h1 class="mt-6 text-2xl">Availability</h1>
    <p class="my-2">
        The calendar below is synced up to my personal and work google
        calendars. Just select a day and a time-slot and I'll confirm with you
        via email.
    </p>
    <hr class="my-6" />
    <CalendarComponent client:load /> <-- This is the problem -->
</Shell>

I just needed to remove the client:load directive:

<CalendarComponent />

Previously I had assumed that the client:load directive was required because I was loading an inline script. I erroneously assumed that meant the calendar was “reactive” and need to be loaded client-side only. But as it turns out… nope. Just slap it in a .astro file and it’ll just render as plain HTML with an inline script. Easy as that.

To be fair to my poor, past, naive self, this is the power of Astro. In an insultingly-reductive way, it’s “just” super-charged HTML templating, with the option to power things interactively with javascript when you need to. It was just the “when you need to” part that I was missing.

The Slightly-Unsatisfying Conclusion

The astute readers among you might remember that this file hadn’t changed in several days. So why did it suddenly start failing? The unsatisfying answer is “I have no clue.” I asked the developer who helped me fix the issue and neither of us had any idea why it would’ve suddenly started failing to build.

Unfortunately computers just be like that sometimes, you know?