Integrate extension examples and add Extension Examples sidebar in Playground

[MUFFANUJ]

Closes #25

I was particularly excited to work on implementing this. This PR introduces the following changes:

• Adds jupyterlab/extension-examples as a git submodule
• Lists discovered examples from jupyterlab/extension-examples.
• Refactors code to reuse generalized sidebar, list, and button styling patterns
• Updates the Binder setup (binder/postBuild) to ensure examples are available
• Adds a generic sidebar open helper for both the token and example tabs in tests
• Adds tests to verify that examples are present and that clicking Open opens the example file

[github-actions]

👈 Launch a Binder on branch MUFFANUJ/jupyterlab-plugin-playground/integrateExtExamples

[krassowski]

To explore:

• maybe this should be a single panel with two collapsible sections (as in debugger, extension manger etc).
• what is the UX when installed locally without the submodule?
  • should it show instructions to clone the subfolder? Ideal UX would be 1-click but there are larger technical choices, so let's track this in a new issue for this PR I would just suggest adjusting instructions (local users who install from PyPI would not have submodules)
  
• it should work on lite too: https://jupyterlab-plugin-playground--86.org.readthedocs.build/en/86/lite/lab/index.html?path=example.ts this means modifying the jupyterlite build script to fetch and embed the examples repo
• opening source code of index.ts is good, but after running an example we don't necessarily see what it should do. Maybe also "Open README" button? Not sure we need to explore this a bit
• Follow-up issue: all examples should have deactivate() and we should call it (c-f Add support for lumino plugin deactivation #54) so that we can modify an example and run it again without an error

[Copilot]

Pull request overview

Integrates jupyterlab/extension-examples into the Plugin Playground and adds an “Extension Examples” section in a consolidated right sidebar, including discovery/opening support and build-time syncing for docs/Binder.

Changes:

• Added a combined Playground sidebar (accordion) containing Service Tokens and Extension Examples sections.
• Implemented runtime discovery/opening of examples under extension-examples/ and added UI tests for example listing/opening.
• Updated docs/Binder configuration to ensure example content is available (via submodule init or fallback clone) and synced into Lite docs content.

Reviewed changes

Copilot reviewed 12 out of 14 changed files in this pull request and generated 4 comments.

Show a summary per file

File	Description
ui-tests/tests/plugin-playground.spec.ts	Refactors sidebar-opening helper and adds an end-to-end test for discovering/opening an extension example.
style/icons/examples-sidebar.svg	Adds a new sidebar icon for the examples section.
style/base.css	Refactors shared sidebar/list/button styles and adds example error styling.
src/token-sidebar.tsx	Adopts generalized sidebar/list/button CSS classes while keeping token-specific hooks.
src/index.ts	Adds ExampleSidebar integration, combined SidePanel accordion, example discovery/opening, and plugin reload deactivation improvements.
src/icons.ts	Registers the new examples sidebar LabIcon.
src/example-sidebar.tsx	Introduces a new ReactWidget sidebar for listing/filtering/opening extension examples with empty/error states.
extension-examples	Adds jupyterlab/extension-examples as a git submodule pointer.
docs/conf.py	Ensures examples are available and syncs them into docs/content for Lite builds.
binder/postBuild	Ensures examples are present in Binder via submodule init or fallback clone.
README.md	Updates user-facing documentation for the new combined sidebar and example setup.
.readthedocs.yaml	Enables recursive submodule checkout on Read the Docs.
.gitmodules	Adds the extension-examples submodule configuration.
.gitignore	Ignores generated docs/content/extension-examples/ synced content.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[MUFFANUJ]

self review :)

[krassowski]

Did you intend to collapse both as startup?

UX-wise the earlier behaviour seemed better to me as the examples/tokens were more discoverable.

[MUFFANUJ]

Did you intend to collapse both as startup?

Yes, I thought that they looked off with lots of information, since you suggested earlier one was better will revert it :)

[krassowski]

Hmm would it be better done with playwright instead? I am worried that this does not reflect the actual typescript code paths that we use in the extension code - it does test the known modules but not the other parts.

[krassowski]

I'm mostly curious what you think about this/whether you tried using playwright. Depending on that the recommendation would be either to merge as is or to drop this script and merge and iterate - I don't think we should hold this PR for tests, but that should be the next step.

[MUFFANUJ]

In my initial commits, I did try writing Playwright tests for this functionality. The main issue I ran into was that the examples list can take time to load, so it would likely need a longer timeout, which would make the test slower and possibly flaky. Since there are a few more actions involved in the flow, the test also started to feel fairly heavy.

I had also modified the existing Galata test earlier, but that was really just a dummy test for the open-file functionality here: plugin-playground.spec.ts#L106-L107

Because of that, I thought it would still be useful to at least have something lightweight that checks the modules/import side as a test, even if it does not cover the full browser code path. I can definitely try writing Playwright tests again if needed, but I was thinking we could merge this first and then iterate with better runtime/UI tests in a follow-up.

[krassowski]

Thank you - let's merge and iterate