Small opinionated change: I think it makes sense for components to live in lib and any static data (like route definitions) to go in routes, so I moved this to routes/navigation.ts (a sibling file to the +layout.svelte which uses it). This keeps lib dotcom-agnostic.

This was necessary because the "About Sourcegraph" entry links to /, which prefixes every path, so it was always being shown as active. I think this is okay since we do not have sub-paths for these pages. The alternative was to add overridable "isCurrent" logic to every entry, which didn't feel ideal.

Should I be depending on window.context directly here?

Good question. I know @vovakulikov has some thoughts around keeping dotcom differences managable.

Maybe we could do it similar to data loading: Pages/components should not access window.context directly. Instead it should only be accessed in data loaders. So in this case the root layout data loader could return the navigation entries.

No idea whether that's good or not.

I was thinking about this recently: how sourcegraphDotCom checks consumed our codebase and how painful it is working with these conditions in UI when you have to think about different layouts in different environments.

Ideally, I would have a different place, like a dotcom directory, where I keep all specific to dotcom logic/UI.
Then, in the app, I would add some extension points with which we could extend the main app with dotcom logic.

The problem is that this isn't usually trivial. Sometimes, UI and logic are combined and coupled very closely.
In this particular example, it's simple enough because the dotcom difference doesn't have anything with UI, but with the data that we provide, this is the best-case scenario. If some page is very different on dotcom compared to the main app I would redo this page from scratch with some env-agnostic components rather than populate it with checks.

Back to this specific change here, I don't have a clear thought on how exactly we should achieve this clear separation between different environments, I would try to not working with check in the UI (which this PR doesn't do, which is great) and see how other dotcom parts will go into the main app, and then come up with more specific idea

I like the idea of putting the window.context accesses in the data loaders. It makes sense to me. And separates concerns a little better. It's not obvious to me that window.context will always be the source of this information.

Maybe we could do it similar to data loading: Pages/components should not access window.context directly. Instead it should only be accessed in data loaders. So in this case the root layout data loader could return the navigation entries.

No idea whether that's good or not.

Ah, I thought we could return the actual navigation entries from here, making the page complete unaware of dotcom mode.
But as Vova said, sometimes it might not be as easy to do (though maybe we should work towards this), so this is probably good enough for now.

Ah! I see. That makes sense. Went ahead and passed the entries here to make the page entirely unaware of dotcom mode.