# Migration Guide This guide provides an overview of major (potentially breaking) changes and the steps to follow to update JupyterLite from one version to another. ## `v0.7.0` to `v0.8.0` ### Extensions JupyterLite 0.8.0 is based on JupyterLab 4.6 and Jupyter Notebook 7.6 packages. This update may affect the extensions you are using, as they may rely on features introduced in JupyterLab 4.6 and Notebook 7.6. ### Build System JupyterLite 0.8.0 switches from [webpack](https://webpack.js.org/) to [rspack](https://rspack.dev/) for bundling. This change follows the upstream JupyterLab migration to rspack, which provides significantly faster build times while maintaining full compatibility with webpack configurations and plugins. This change should be transparent for most users. However, if you have custom build configurations that extend or modify the JupyterLite webpack configuration, you may need to update your setup to use rspack instead. ### Relative Path Resolution for `contents` and `workspaces` Relative paths specified in `contents` and `workspaces` configuration options (via `jupyter_lite_config.json`, `jupyter_lite_config.py`, or the CLI) are now resolved relative to `lite_dir` instead of the current working directory. This fix ensures consistent behavior when running `jupyter lite build --lite-dir ` from a different directory. If your build relied on paths being resolved relative to the working directory, you may need to adjust your configuration. ### Contents and Workspaces Indexing The `all.json` files used for indexing contents and workspaces are no longer hardcoded in the frontend. Instead, the build addons now populate `contentsAllJsonFile` and `workspacesAllJsonFile` as `PageConfig` options in `jupyter-lite.json` at build time. The frontend checks for these options before attempting to fetch the index files. If the options are not present (e.g. when no contents or workspaces were provided during the build), the fetch is skipped entirely. This avoids unnecessary requests to the server and eliminates spurious 404 errors that previously appeared in the browser's developer console. This change should be transparent for most users. However, if you have custom code that relies on fetching `all.json` directly from `api/contents/` or `api/workspaces/`, you should update it to read the filename from `PageConfig` instead: ```typescript import { PageConfig } from '@jupyterlab/coreutils'; const contentsAllJsonFile = PageConfig.getOption('contentsAllJsonFile'); const workspacesAllJsonFile = PageConfig.getOption('workspacesAllJsonFile'); ``` ### Build Optimization Settings The switch to rspack may affect some build optimization settings due to changes in the internal bundle format. If you were using `--no-unused-shared-packages` or `--no-sourcemaps` flags and notice unexpected behavior, please report it to the [JupyterLite issue tracker](https://github.com/jupyterlite/jupyterlite/issues). ### Removed Packages The `@jupyterlite/iframe-extension` package has been removed. This package provided a MIME renderer for the `text/html-sandboxed` MIME type, which rendered HTML content inside sandboxed iframes in notebook outputs. This functionality is no longer needed as JupyterLab's built-in HTML renderer can be used instead. If you need to display HTML content in your notebooks, you can use the `IPython.display.HTML` class: ```python from IPython.display import HTML HTML("

Hello, World!

") ``` If you specifically need iframe-based rendering, you can use `IPython.display.IFrame`: ```python from IPython.display import IFrame IFrame(src="https://example.com", width=800, height=400) ``` If your JupyterLite deployment or custom application referenced this extension, you should remove it from your configuration. ## `v0.6.0` to `v0.7.0` ```{warning} JupyterLite 0.7.0 comes with a couple of major changes that may be considered breaking, depending on your JupyterLite setup. Please read the following sections carefully to check if you are impacted by these changes ``` ### Extensions JupyterLite 0.7.0 is based on JupyterLab 4.5 and Jupyter Notebook 7.5 packages. This update may affect the extensions you are using, as they may rely on features introduced in JupyterLab 4.5 and Notebook 7.5. ### `jupyterlite-core` Support for Python 3.9 has been dropped. `jupyterlite-core` now requires Python 3.10 or higher. ### Package Consolidation ```{warning} The individual service packages have been deprecated in favor of the unified `@jupyterlite/services` package, and the `@jupyterlite/server` package has been deprecated in favor of `@jupyterlite/apputils`. ``` Starting with JupyterLite 0.7.0, the following packages have been deprecated and their functionality has been consolidated into the `@jupyterlite/services` package: - `@jupyterlite/kernel` - `@jupyterlite/contents` - `@jupyterlite/session` - `@jupyterlite/settings` Additionally, the `@jupyterlite/server` package has been deprecated, with its service worker management functionality moved to the `@jupyterlite/apputils` package. These changes were made to more closely follow the package structure used by JupyterLab and to better organize utility functions within the codebase. If your extension or application was importing from these individual packages, you should update your imports accordingly. See the sections below for concrete migration examples. #### Migration to `@jupyterlite/services` The `@jupyterlite/services` package consolidates all service-related functionality and provides all the same exports as the individual packages. ##### Example 1: Kernel Extension If you have a custom kernel extension, update your imports: ```diff -import { IKernelSpecs } from '@jupyterlite/kernel'; +import { IKernelSpecs } from '@jupyterlite/services'; ``` ##### Example 2: Storage Management If you're working with the browser storage drive or settings: ```diff -import { BrowserStorageDrive } from '@jupyterlite/contents'; -import { Settings } from '@jupyterlite/settings'; +import { BrowserStorageDrive, Settings } from '@jupyterlite/services'; ``` ##### Example 3: Session Management For session management: ```diff -import { LiteSessionClient } from '@jupyterlite/session'; +import { LiteSessionClient } from '@jupyterlite/services'; ``` #### Migration to `@jupyterlite/apputils` The `@jupyterlite/server` package has been deprecated in favor of `@jupyterlite/apputils`, which now provides the service worker management functionality. ##### Import Updates Update your imports to use `@jupyterlite/apputils` instead: ```diff -import { IServiceWorkerManager, ServiceWorkerManager } from '@jupyterlite/server'; +import { IServiceWorkerManager, ServiceWorkerManager } from '@jupyterlite/apputils'; ``` The token identifier changed from: - `'@jupyterlite/server:IServiceWorkerManager'` to `IServiceWorkerManager` (imported from `@jupyterlite/apputils`) ```{note} The `@jupyterlite/server` package will continue to work as a re-export from `@jupyterlite/apputils` for backward compatibility, but it is recommended to update your imports to use `@jupyterlite/apputils` directly. ``` ## `v0.5.0` to `v0.6.0` ```{warning} JupyterLite 0.6.0 comes with a couple of major changes that may be considered breaking, depending on your JupyterLite setup. Please read the following sections carefully to check if you are impacted by these changes ``` ### Extensions JupyterLite 0.6.0 is based on JupyterLab 4.4 and Jupyter Notebook 7.4 packages. This update may affect the extensions you are using, as they may rely on features introduced in JupyterLab 4.4 and Notebook 7.4. ### Contents #### File indexing with `jupyter-server` Previously, running a build with the contents option specified (for example with `jupyter lite build --contents contents`) would simply log a warning in the build logs if the `jupyter-server` dependency (used for indexing the files) was missing, making it difficult to debug issues with missing content and files. In JupyterLite 0.6.0, the build now fails if the `contents` option is provided when the `jupyter-server` is not installed. #### Browser Storage Previously, the default contents manager was storing files in the browser's local storage (IndexedDB by default), under the "JupyterLite Storage" key. This had the effect of "sharing" files across different deployments of JupyterLite under the same origin, leading to some confusions for the users. Starting with JupyterLite 0.6.0, the default contents manager now uses the base URL in the storage key. For example if you have the following two JupyterLite deployments under the same origin: - `https://example.com/lite1` - `https://example.com/lite2` The contents will be stored under the following keys: - `JupyterLite Storage - /lite1` - `JupyterLite Storage - /lite2` This means that if you or your users had previously created files in one of the deployments, they will not be available anymore. To use the same default name for the contents storage as before, you can set the `contentsStorageName` option in your `jupyter-lite.json` file to `JupyterLite Storage`. For example: ```json { "jupyter-lite-schema-version": 0, "jupyter-config-data": { "contentsStorageName": "JupyterLite Storage" } } ``` ### Settings Similar to the contents storage mentioned in the section above, the default settings storage is now using the base URL in the storage key. This means that if you or your users had previously changed a few settings in the interface, for example the theme, those settings will not be applied after the update to JupyterLite 0.6.0. To configure a custom settings storage name, you can set the `settingsStorageName` option in your `jupyter-lite.json` file. For example: ```json { "jupyter-lite-schema-version": 0, "jupyter-config-data": { "settingsStorageName": "JupyterLite Storage" } } ``` ### API Changes Prior to version 0.6.0, JupyterLite divided extensions into two categories: - Regular JupyterLab extensions, loaded the same way as in JupyterLab - "serverlite" extensions, loaded on a separate Lumino application, such as custom kernels To replace default serverlite plugins or add extra "server" functionalities, extension authors had to provide a `JupyterLiteServerPlugin`. Starting with JupyterLite 0.6.0, all plugins are registered with the same plugin registry, including kernels and other "server" plugins such as the kernel and session managers. These plugins are now regular `JupyterFrontEndPlugin` instances, or `ServiceManagerPlugin` instances (introduced in JupyterLab 4.4). As a result, extensions no longer need to use the `"liteExtensions": true` field in their `package.json` file. This field was previously used to indicate that an extension was a "serverlite" extension. Below are the changes in the different packages resulting from this architectural change. #### How to migrate your kernel If you have authored a custom kernel, it should continue loading correctly in JupyterLite 0.6.0. However, you may want to make the following changes to your kernel extension: - Update the plugin definition to use `JupyterFrontEndPlugin` instead of `JupyterLiteServerPlugin`: ```diff /** * A plugin to register the custom kernel. */ -const kernel: JupyterLiteServerPlugin = { +const kernel: JupyterFrontEndPlugin = { id: 'my-custom-kernel:plugin', autoStart: true, requires: [IKernelSpecs], - activate: (app: JupyterLiteServer, kernelspecs: IKernelSpecs) => { + activate: (app: JupyterFrontEnd, kernelspecs: IKernelSpecs) => { kernelspecs.register({ spec: { name: 'custom', ``` #### Service Worker ##### Plugin Name The service worker plugin, which synchronizes content between the JupyterLite file browser and the kernel when `SharedArrayBuffer` is not available, has been moved to the `@jupyterlite/application-extension` package. If you were disabling the Service Worker in a custom `jupyter-lite.json` file, you will need to update the plugin name to disable as follows: ```diff { "jupyter-lite-schema-version": 0, "jupyter-config-data": { - "disabledExtensions": ["@jupyterlite/server-extension:service-worker"] + "disabledExtensions": ["@jupyterlite/application-extension:service-worker-manager"] } } ``` ##### Service Worker communication The Service Worker communicates with the main thread using a `BroadcastChannel`. In previous versions, the broadcast channel was made available to kernels via `IBroadcastChannelWrapper` and was provided by the `@jupyterlite/server-extension:emscripten-filesystem` plugin. Starting with JupyterLite 0.6.0, the Service Worker Manager plugin manages the `BroadcastChannel` directly through the `@jupyterlite/application-extension:service-worker-manager` plugin. The `BroadcastChannel` now also handles stdin requests, in addition to drive requests. As a consequence: - `IBroadcastChannelWrapper` has been removed from the `@jupyterlite/server` package. - The `@jupyterlite/server-extension:emscripten-filesystem` plugin has been removed from the `@jupyterlite/server-extension` package. - The `BroadcastChannel` id was renamed from `'/api/drive.v1'` to `'/sw-api.v1'`. `IBroadcastChannelWrapper` and the `@jupyterlite/server-extension:emscripten-filesystem` plugin were primarily used to provide a convenience wrapper around the `BroadcastChannel` used for file system access. This functionality is now handled by the `@jupyterlite/application-extension:service-worker-manager` plugin and its `IServiceWorkerManager` service. If you have a custom kernel and need to enable file system access, refer to the implementation in the [Pyodide kernel](https://github.com/jupyterlite/pyodide-kernel). #### `@jupyterlite/server` The following classes and interfaces have been removed: - `JupyterLiteServer` - `JupyterLiteServerPlugin` - `Router` #### `@jupyterlite/application` The `registerPluginModule` and `registerPluginModules` methods have been removed from the `SingleWidgetApp` class. If you were creating your own `SingleWidgetApp` instance and using these methods to register plugins, you should now use a `PluginRegistry` instead. The `PluginRegistry` is now the central mechanism for managing and resolving plugins in JupyterLab 4.4 and JupyterLite 0.6.0. The `PluginRegistry` provides a more centralized approach to plugin management, allowing you to register plugins before creating the application instance and resolve services through the registry. #### `@jupyterlite/kernel` The previous `Kernels` class (and its `IKernels` interface), used for managing kernels in the browser, have been renamed to `LiteKernelClient` and `IKernelClient` respectively. `IKernelClient` now extends `IKernelAPIClient` provided by `@jupyterlab/services`. #### `@jupyterlite/session` The previous `Sessions` class, used for managing sessions in the browser, has been renamed to `LiteSessionClient`, which now implements the `ISessionAPIClient` interface from `@jupyterlab/services`. #### `@jupyterlite/contents` The previous `Contents` class, used for managing contents in the browser, has been renamed to `BrowserStorageDrive`, and now implements the `IDrive` interface from `@jupyterlab/services`. This drive is now provided as the default drive via `IDefaultDrive`. The `ContentsAPI` and `ServiceWorkerContentsAPI` classes now take an `options` object as an argument for their `constructor`. #### `@jupyterlite/licenses` ```{warning} The `@jupyterlite/licenses` package has been removed in JupyterLite 0.6.0. ``` The `Licenses` class, used for managing licenses in the browser, has undergone significant API changes. It now implements the `ILicensesClient` interface from `@jupyterlab/apputils` and is provided as a plugin via the `@jupyterlite/apputils-extension:licenses-client` plugin. #### `@jupyterlite/server-extension` The `@jupyterlite/server-extension` package has been removed. The JupyterLite services plugins (kernel, session, contents, settings, etc.) are now provided by the `@jupyterlite/services-extension` package as `ServiceManagerPlugin` plugins. #### `@jupyterlite/settings` The previous `Settings` class, used for managing settings in the browser, has replaced the default `Setting.IManager` provided by JupyterLab. Its API has been changed accordingly to fulfill the `Setting.IManager` interface. The `@jupyterlite/settings` package no longer exports any tokens. #### `@jupyterlite/translation` ```{warning} The `@jupyterlite/translation` package has been removed in JupyterLite 0.6.0. ``` Translations are now supported by implementing the `ITranslatorConnector` interface provided by JupyterLab, which is then exposed via the `@jupyterlite/apputils-extension:translator-connector` plugin. ## `v0.4.0` to `v0.5.0` ### Extensions JupyterLite 0.5.0 is based on the JupyterLab 4.3 and Jupyter Notebook 7.3 packages. Although no breaking changes are expected, this may affect the extensions you are using as they may rely on features added to JupyterLab 4.3 and Notebook 7.3. See the JupyterLab and Notebook changelogs for more information: - [JupyterLab 4.3](https://jupyterlab.readthedocs.io/en/stable/getting_started/changelog.html#v4-3) - [Jupyter Notebook 7.3](https://jupyter-notebook.readthedocs.io/en/stable/changelog.html#v7-3) ### `jupyterlite-core` Support for Python 3.8 has been dropped. `jupyterlite-core` now requires Python 3.9 or higher. ### API Changes #### `@jupyterlite/kernel` The `IKernel` interface now includes a `changed` signal which is emitted when a kernel is started or stopped. This should only affect extensions implementing that interface to provide a custom kernel manager for JupyterLite. ### Configuration The following configuration options were removed from the [JupyterLite schema](./reference/schema-v0.rst): - `collaborative` - `fullWebRtcSignalingUrls` ## `v0.3.0` to `v0.4.0` ### Extensions JupyterLite 0.4.0 is based on the JupyterLab 4.2 and Jupyter Notebook 7.2 packages. Although no breaking changes are expected, this may affect the extensions you are using as they may rely on features added to JupyterLab 4.2 and Notebook 7.2. See the JupyterLab and Notebook changelogs for more information: - [JupyterLab 4.2](https://jupyterlab.readthedocs.io/en/stable/getting_started/changelog.html#v4-2-0) - [Jupyter Notebook 7.2](https://jupyter-notebook.readthedocs.io/en/stable/changelog.html#v7-2) ### Accessing files from the kernel JupyterLite 0.4.0 introduces a more robust way for accessing files from kernels. Previously, JupyterLite was relying on a Service Worker to make the files visible to the kernel. Starting with version 0.4.0, JupyterLite allows kernels to leverage the use of shared memory (via `SharedArrayBuffer`) to make accessing files more robust and resilient, and avoid caching issues. If the COOP and COEP headers are set, JupyterLite uses shared memory via `SharedArrayBuffer` to enable file access. Otherwise, it defaults to using the Service Worker, like before. See the [documentation on accessing files](./howto/content/python.md) for more information. ### API changes #### `@jupyterlite/application` - The signature of the `currentChanged` signal for the `SingleWidgetShell` has changed from `ISignal` to `ISignal>`. This follows this change in JupyterLab: [Add `IShell.currentChanged` and notify commands based on it](https://github.com/jupyterlab/jupyterlab/pull/15449) #### `@jupyterlite/contents` package The TypeScript interface `IEmscriptenNodeOps` has changed. All methods now take `IEmscriptenFSNode | IEmscriptenStream` as input instead of only `IEmscriptenFSNode`. Classes implementing `IEmscriptenNodeOps` will need to be updated accordingly. See https://github.com/jupyterlite/jupyterlite/pull/1395 for an example implementation. The TypeScript interface `IDriveRequest` has been removed. It has been replaced by the type definition `TDriveRequest`. This allows to have a more refined typing depending on the type of request. The same goes for the drive response type `TDriveResponse`. For example, a 'readdir' drive request would have the type `TDriveRequest<'readdir'>`, and its response would be of the type `TDriveResponse<'readdir'>`. A new class `DriveContentsProcessor` is provided, which allows to perform drive requests using the jupyterlite contents manager. It can be used by Emscripten kernel authors in combination to extending the abstract `ContentsAPI` class in order to provide a custom way to implement file access from the kernel (e.g. bypassing the service worker approach). ## `v0.2.0` to `v0.3.0` ### Extensions JupyterLite 0.3.0 is based on the JupyterLab 4.1 and Jupyter Notebook 7.1 packages. Although no breaking changes are expected, this may affect the extensions you are using as they may rely on features added to JupyterLab 4.1 and Notebook 7.1. ### `jupyterlite` metapackage Prior to JupyterLite 0.3.0, installing the `jupyterlite` metapackage would also install the JavaScript (Web Worker) kernel by default via the dependency on `jupyterlite-javascript-kernel`. This dependency on `jupyterlite-javascript-kernel` has now been removed, so you may need to explicitly add `jupyterlite-javascript-kernel` to your build dependencies if you want to use that kernel. ```{note} As an alternative to `jupyterlite-javascript-kernel`, you may also want to use [Xeus JavaScript], which currently offers more features and is generally more usable. ``` ```{note} `jupyterlite-javascript-kernel` has now been moved to the [jupyterlite-javascript-kernel] repo. ``` [Xeus JavaScript]: https://github.com/jupyter-xeus/xeus-javascript [jupyterlite-javascript-kernel]: https://github.com/jupyterlite/javascript-kernel ### Service Worker JupyterLite uses a Service Worker to make files and notebooks visible to the kernels, so they can be manipulated by the user via code in the notebook. In previous versions, the Service Worker had caching enabled by default, and it was not possible to easily disable it. The Service Worker cache was however the source of many issues when accessing files from a kernel, often giving errors to users, who would have to clear their cache to fix the issue. In JupyterLite 0.3.0, the Service Worker cache is **disabled** by default, but it is still possible to enable it if needed. To enable the Service Worker cache, add the `enableServiceWorkerCache` option to your `jupyter-lite.json` file. For example: ```json { "jupyter-lite-schema-version": 0, "jupyter-config-data": { "enableServiceWorkerCache": true } } ``` ## `v0.1.0` to `v0.2.0` ### Extensions JupyterLite 0.2.0 is based on the JupyterLab 4 and Jupyter Notebook 7 packages. JupyterLab 4 comes with a couple of breaking changes which likely affect extensions. If you were using JupyterLab 3 extensions in your JupyterLite deployment, you might have to update to a newer version of the extension that is compatible with JupyterLab 4. ```{note} For extensions authors, check out the [extension migration guide](https://jupyterlab.readthedocs.io/en/latest/extension/extension_migration.html) in the JupyterLab documentation. ``` ### Jupyter Notebook 7 In JupyterLite 0.1.x the Notebook interface was provided by [RetroLab](https://github.com/jupyterlab/retrolab). In JupyterLite 0.2.0, the Notebook interface is now provided by [Jupyter Notebook 7](https://github.com/jupyter/notebook) Jupyter Notebook 7 is the successor of RetroLab and the Classic Notebook, based on JupyterLab components. This means the URLs have also changed to be aligned with the ones provided by Jupyter Notebook 7: - `/retro/consoles` -> `/consoles` - `/retro/edit` -> `/edit` - `/retro/notebooks` -> `/notebooks` - `/retro/tree` -> `/tree` ### `jupyterlite` metapackage In version `0.1.x`, installing the `jupyterlite` metapackage would automatically install the Pyodide kernel by default, since the `jupyterlite` metapackage would depend on `jupyterlite-pyodide-kernel`. In version `0.2.0` this is not the case anymore. You will need to install the `jupyterlite-pyodide-kernel` explicitly in your build environment alongside `jupyterlite-core` (the package providing the `jupyter-lite` CLI). See [the documentation for adding kernels](./howto/configure/kernels.md) to learn more. ### Service Worker The service worker file name has been changed. In `0.1.0`, it was `service-worker-[hash].js` with the `hash` computed by webpack, in `0.2.0` the hash is removed and the new file name is `service-worker.js`. ### API changes #### `jupyterlite-core` - The Mathjax addon was removed from the `jupyterlite-core` package. As a consequence the `mathjaxConfig` and `fullMathjaxUrl` options in `jupyter-lite.json` can be removed as they do not have any effect anymore. If you would like to use Mathjax 2, it's possible to install `jupyterlab-mathjax2`. See the [jupyter-renderers](https://github.com/jupyterlab/jupyter-renderers) repository for more information. For reference, see the [JupyterLab Pull Request that updated to Mathjax 3](https://github.com/jupyterlab/jupyterlab/pull/13877) #### `@jupyterlite` packages These API changes are only relevant if you are reusing `@jupyterlite` packages in downstream applications. - The `IKernel` interface exposed by `@jupyterlite/kernel` has a new `get` method to retrieve a running kernel by id. ## `0.1.0b19` to `0.1.0b20` ### `jupyterlite-core` The static assets distributed via the `jupyterlite-core` package do not include the JavaScript kernel anymore. Instead the JavaScript kernel is now distributed via the separate `jupyterlite-javascript-kernel` package. If you would like to include the JavaScript kernel in your deployment you will have to first install it before building the JupyterLite site. For example with: ``` python -m pip install jupyterlite-javascript-kernel ``` Or add it to the [LiteBuildConfig/federated_extensions](https://jupyterlite.readthedocs.io/en/latest/howto/configure/advanced/extensions.html#adding-custom-extensions) config entry. Currently the `jupyterlite` package still includes the JavaScript kernel via a dependency on `jupyterlite-javascript-kernel`. But this might change in a future version. We recommend you start using the `jupyterlite-core` package directly for your deployments, and explicitly add more kernels such as `jupyterlite-pyodide-kernel` or `jupyterlite-javascript-kernel`. ## `0.1.0b18` to `0.1.0b19` ### `jupyterlite-core` This release introduces a new `jupyterlite-core` package in addition to the existing `jupyterlite` package. The `jupyterlite-core` package provides the core functionality for building JupyterLite websites and CLI [extension points](https://jupyterlite.readthedocs.io/en/latest/howto/extensions/cli-addons.html). Currently it only includes a JavaScript kernel that runs in a Web Worker. If you would like to include a Python kernel in your deployment you will have to first install it before building the JupyterLite site. For example with: ``` python -m pip install jupyterlite-pyodide-kernel ``` Or add it to the [LiteBuildConfig/federated_extensions](https://jupyterlite.readthedocs.io/en/latest/howto/configure/advanced/extensions.html#adding-custom-extensions) config entry. The `jupyterlite` package currently provides a couple of shims as well as the Pyodide kernel for better compatibility with existing deployments. We recommend you start using the `jupyterlite-core` package for your deployments, and additionally install a Python kernel such as `jupyterlite-pyodide-kernel` or a Xeus kernel. ### `jupyterlite-pyodide-kernel` The Pyodide kernel has been moved to its own repo: [https://github.com/jupyterlite/pyodide-kernel](https://github.com/jupyterlite/pyodide-kernel) Currently it is still installed by default with `jupyterlite` for convenience, but it is not part of `jupyterlite-core`. A consequence of this change is the renaming of the `pyolite` JavaScript packages: - `@jupyterlite/pyolite-kernel` -> `@jupyterlite/pyodide-kernel` - `@jupyterlite/pyolite-kernel-extension` -> `@jupyterlite/pyodide-kernel-extension` Make sure to update your config if you were making use of `litePluginSettings`. ## `0.1.0b17` to `0.1.0b18` The JavaScript kernel now runs in a Web Worker instead of an IFrame, to streamline how default kernels run in JupyterLite. This might affect custom kernel authors extending the base `JavaScriptKernel` like https://github.com/jupyterlite/p5-kernel. This was changed in the following PR: [#711](https://github.com/jupyterlite/jupyterlite/pull/711) ## `0.1.0b16` to `0.1.0b17` ### Use `PipliteAddon.piplite_urls` instead of `LiteBuildConfig.piplite_urls` If you were configuring the `piplite_urls` option (described in https://jupyterlite.readthedocs.io/en/latest/howto/pyodide/wheels.html) to ship additional wheels at build time, this configuration option has now been moved from `LiteBuildConfig.piplite_urls` to `PipliteAddon.piplite_urls`. If using a `jupyter_lite_config.json` file, the configuration should look like the following: ```json { "PipliteAddon": { "piplite_urls": ["url-to-wheel1", "url-to-wheel2", "..."] } } ``` This was changed in the following PR: [#934](https://github.com/jupyterlite/jupyterlite/pull/934)