The lookup time is still constant thanks to hash key lookup. The keys being ordered is a separate part of the same data structure.

Strongly agree. Every project I've ever seen use CRA has eventually had to wrestle with its constraints and sooner or later they have to make the hard choice to eject or not. Either way, they seem to regret it :-D

In general, any time you see "foo is not a function" that suggests that you have an undefined reference. If you've followed along with the post above, the possible points of failure are either forgetting to jest.mock the relevant module path (e.g. jest.mock('my/path') ) or forgetting to cast a mock type using the original type as the base (e.g. const mockFoo = foo as jest.MockedFunction<typeof foo> ).

Thank you, Marcelo! It's comments like these that make me excited to keep writing articles in the future.

That's a great point! I'll update the article to make that clear. EDIT: I have made an update now and called out the in-place sorting in a few parts of the post. Thanks again for pointing this out!

Honestly, I've not had much experience with workspaces. My usual inclination would be to coordinate via npm packages. But I know that's not everyone's preference. I'd be really interested to read a write-up on how exactly the build process I've described above would need to change in a multi-workspace monorepo.

Steve Barakat Yup, that's exactly it! I want the code I write to be as easy to use as possible for people that depend on it. Maybe the difference between from 'Button/Button' and from 'Button' isn't much, but it is something I can do to help even if only a little. The tradeoff is it means I need to have a top-level index file that re-exports everything from a single entry point.

Hey good question! I recommend having a single higher level index.ts that gathers together everything you want to export from your library. Guessing from the folder structure you have pictured, you could have an index.ts at: src/index.ts Which contains: export { DualRangeSlider } from './components/DualRangeSlider' export { DualVerticalRangeSlider } from './components/DualVerticalRangeSlider' // etc Then your build process just needs to point at that single index file to bundle up everything you want your library to expose. I'm doing this in the example provided in the article, but it's probably not obvious because I only have a single example component to re-export. But that same pattern works for any number of components, as long as they each have an entry in the top-level index file. I'll make an edit to the article to make this clearer when I have some time on the weekend 🙂