Allow for frontend driven indexing

[jtpio]

Fixes #50
Replaces #52

• Add a setting to index files from the frontend directly (enabling the use in JupyterLite)
• Keep the server extension as the default
• Add a depth setting to control the max search depth
• JupyterLite deployment on GitHub Pages

jupyterlab-quickopen-depth-frontend.mp4

[github-actions]

👈 Launch a Binder on branch jupyterlab-contrib/jupyterlab-quickopen/support-jupyterlite

[jtpio]

The build JupyterLite archive seems to be working fine, with the frontend indexing set by default:

jupyterlab-quickopen-lite.mp4

[Copilot]

Pull Request Overview

This PR adds frontend-driven file indexing support to enable JupyterLite compatibility while maintaining the existing server-based indexing as the default. It restructures the codebase to use a provider pattern and adds depth control for search operations.

• Adds a frontend provider using JupyterLab's Contents API for JupyterLite environments
• Introduces configurable search depth limits for both frontend and server indexing
• Creates a JupyterLite demo deployment with GitHub Pages integration

Reviewed Changes

Copilot reviewed 14 out of 15 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
src/widget.ts	Extracted QuickOpenWidget class from index.ts with updated provider interface
src/tokens.ts	Enhanced provider interface with options object and depth parameter
src/serverProvider.ts	Renamed from defaultProvider.ts, updated to use new options interface
src/index.ts	Refactored to use provider pattern with dynamic provider switching
src/handler.ts	Removed unused API handler utilities
src/frontendProvider.ts	New frontend implementation using Contents API for JupyterLite
schema/plugin.json	Added indexingMethod and depth configuration settings
jupyterlab_quickopen/handler.py	Added depth parameter support to server endpoint
demo/*	Added JupyterLite demo configuration files
.github/workflows/deploy.yml	Added GitHub Pages deployment workflow

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[martinRenou]

Thanks! I only have a small question, otherwise it looks great :)

[martinRenou]

I guess this is for JupyterLite support?

Long-term, we may want to extend the contentsManager implementation so that we don't need to make the recursive gets here?

[jtpio]

Yes, indeed, this one is only for the frontend provider, so the provider making the calls to the contents API one by one.

we may want to extend the contentsManager implementation

You mean extending it directly in Jupyterlite? If so yes, that could be an option. Also the quickopen provider is defined in its own plugin, so it could be replaced by another plugin provided by JupyterLite.

[martinRenou]

You mean extending it directly in Jupyterlite

I guess I mean that if the more advanced handler for recursive get gets into jupyterlab-server, then the contentsManager API will be updated to expose this new recursive get. Then JupyterLite will have to implement it and we can get rid of the recursion here?

[jtpio]

Yes, I guess this FrontendQuickOpenProvider is mostly to enable the use of the extension in JupyterLite, and have everything available in the same jupyterlab-quickopen extension.

If we decide to propose this extension for incorporation into core JupyterLab, we can expose the provider token and drop that custom FrontendQuickOpenProvider, since JupyterLite will be able to provide its own.

[jtpio]

Getting this in a new release.