Some extension subcategories can go missing
Nobody has claimed this yet.
- Dominant language
- TypeScript
- Stars
- 2.3k
- Forks
- 641
- Avg merge
- 12h 4m
- Merged PRs (30d)
- 57
Description
Problem
Loading an extension and then loading a second extension that contains the first can lead to missing subcategories.
Repro Steps
- Open up a Microbit and reset the page or clear the __pxt_apis_microbit indexed db entry.
- Start a new project and load the makerbit-lcd1602 extension. You'll see a
MakerBitcategory in the toolbox withLCD1602andLCD2004subcategories under it. - Load the makerbit extension, which includes the same lcd1602 code. You'll now see that the
LCD2004category is gone while theLCD1602category remains.
If you look for 2004 in the toolbox search bar, you'll still be able to find the LCD2004 blocks.
Expected Behavior
The expected behavior is that the LCD2004 subcategory should not disappear.
Note
The problem probably lies with how namespaces for extensions are defined.
After Loading Just the makerbit-lcd1602 extension
After loading the makerbit extension as well
Searching for the LCD2004 blocks

Desktop:
- OS: Windows 10 1909
- Browser Microsoft Edge v. 86.0.622.56
- makecode.microbit.org version: 3.0.43
- Microsoft MakeCode version: 6.0.28
- microbit runtime version: v2.2.0-rc6
Additional context
Refer to #7562 for additional context.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Reproduce the issue on the Microbit target by loading makerbit-lcd1602, then makerbit, and compare the toolbox categories with the toolbox search results. Start by tracing how extension namespaces and toolbox subcategories are defined and merged; issue #7562 provides additional context. Done means LCD2004 remains visible after both extensions are loaded.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- typescript
- Domain
- frontend
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100