@jbrowse/core 4.3.0 → 5.0.0-beta.2

package/esm/pluggableElementTypes/RpcMethodTypeWithRenameRegion.js

@@ -0,0 +1,18 @@
+import RpcMethodType from './RpcMethodType.js';
+// Singular-region counterpart of RpcMethodTypeWithRenameRegions, for RPC methods
+// whose wire contract carries one `region` (e.g. block-at-a-time wiggle
+// rendering). Subclasses get region renaming for free.
+export default class RpcMethodTypeWithRenameRegion extends RpcMethodType {
+    async serializeArguments(args) {
+        // adapt the singular `region` to the plural renameRegions helper.
+        // `rest`, not `args` — spreading the ORIGINAL back over the result drops
+        // everything renaming adds beside the regions, silently. That is how
+        // `sequenceAdapter` would reach a worker undefined on exactly the
+        // single-region methods while the plural ones got it.
+        const { regions, ...rest } = await this.renameRegions({
+            ...args,
+            regions: [args.region],
+        });
+        return super.serializeArguments({ ...rest, region: regions[0] });
+    }
+}

package/esm/pluggableElementTypes/RpcMethodTypeWithRenameRegions.d.ts

@@ -0,0 +1,5 @@
+import RpcMethodType from './RpcMethodType.ts';
+import type { RenameRegionsArgs } from './RpcMethodType.ts';
+export default abstract class RpcMethodTypeWithRenameRegions<MethodName extends string = string> extends RpcMethodType<MethodName> {
+    serializeArguments<T extends RenameRegionsArgs>(args: T): Promise<Record<string, unknown>>;
+}

package/esm/pluggableElementTypes/RpcMethodTypeWithRenameRegions.js

@@ -0,0 +1,10 @@
+import RpcMethodType from './RpcMethodType.js';
+// Base for RPC methods whose serialize step just maps region refNames into the
+// data adapter's naming scheme. Subclasses get region renaming for free;
+// override serializeArguments only to add extra transforms, calling super to
+// keep the renaming.
+export default class RpcMethodTypeWithRenameRegions extends RpcMethodType {
+    async serializeArguments(args) {
+        return super.serializeArguments(await this.renameRegions(args));
+    }
+}

package/esm/pluggableElementTypes/TextSearchAdapterType.d.ts

@@ -7,12 +7,12 @@ export default class TextSearchAdapterType extends PluggableElementBase {
     description?: string;
     constructor(stuff: {
         name: string;
+        configSchema: AnyConfigurationSchemaType;
         displayName?: string;
         description?: string;
-        configSchema: AnyConfigurationSchemaType;
     } & ({
-        AdapterClass: AnyAdapter;
-    } | {
         getAdapterClass: () => Promise<AnyAdapter>;
+    } | {
+        AdapterClass: AnyAdapter;
     }));
 }

package/esm/pluggableElementTypes/TextSearchAdapterType.js

@@ -1,8 +1,10 @@
-import PluggableElementBase from "./PluggableElementBase.js";
+import PluggableElementBase from './PluggableElementBase.js';
 export default class TextSearchAdapterType extends PluggableElementBase {
     getAdapterClass;
     configSchema;
     description;
+    // `AdapterClass` is retained for backward compatibility with third-party
+    // plugins; new code should prefer `getAdapterClass` for code splitting.
     constructor(stuff) {
         super(stuff);
         this.description = stuff.description;

package/esm/pluggableElementTypes/TrackType.d.ts

@@ -1,6 +1,6 @@
 import PluggableElementBase from './PluggableElementBase.ts';
-import type DisplayType from './DisplayType.ts';
 import type { AnyConfigurationSchemaType } from '../configuration/index.ts';
+import type DisplayType from './DisplayType.ts';
 import type { IAnyModelType } from '@jbrowse/mobx-state-tree';
 export default class TrackType extends PluggableElementBase {
     stateModel: IAnyModelType;
@@ -11,6 +11,7 @@ export default class TrackType extends PluggableElementBase {
         stateModel: IAnyModelType;
         displayName?: string;
         configSchema: AnyConfigurationSchemaType;
+        aliases?: string[];
     });
     addDisplayType(display: DisplayType): void;
 }

package/esm/pluggableElementTypes/TrackType.js

@@ -1,4 +1,4 @@
-import PluggableElementBase from "./PluggableElementBase.js";
+import PluggableElementBase from './PluggableElementBase.js';
 export default class TrackType extends PluggableElementBase {
     stateModel;
     configSchema;

package/esm/pluggableElementTypes/ViewType.d.ts

@@ -1,7 +1,8 @@
-import type React from 'react';
 import PluggableElementBase from './PluggableElementBase.ts';
+import type { LaunchKeyRegistration } from '../util/withLaunchInput.ts';
 import type DisplayType from './DisplayType.ts';
 import type { IAnyModelType, IAnyStateTreeNode } from '@jbrowse/mobx-state-tree';
+import type React from 'react';
 type BasicView = React.ComponentType<{
     model: any;
     session?: IAnyStateTreeNode;
@@ -12,18 +13,41 @@ interface ViewMetadata {
 }
 export default class ViewType extends PluggableElementBase {
     ReactComponent: ViewComponentType;
-    stateModel: IAnyModelType;
+    private loadedStateModel?;
+    get stateModel(): IAnyModelType;
+    stateModelLoader?: () => Promise<IAnyModelType>;
+    private stateModelPromise?;
+    private pendingStateModelExtensions;
+    launchKeys?: LaunchKeyRegistration<unknown, string>;
     displayTypes: DisplayType[];
     viewMetadata: ViewMetadata;
     extendedName?: string;
     constructor(stuff: {
         name: string;
         displayName?: string;
-        stateModel: IAnyModelType;
+        stateModel: IAnyModelType | (() => Promise<IAnyModelType>);
+        launchKeys?: LaunchKeyRegistration<unknown, string>;
         extendedName?: string;
         viewMetadata?: ViewMetadata;
         ReactComponent: ViewComponentType;
+        aliases?: string[];
     });
+    /**
+     * Every key this view accepts written on the view object — its declared MST
+     * properties plus the launch keys above. `undefined` for a view that
+     * registers none: nothing there says which of its launcher's arguments are
+     * settings, so a caller must classify nothing rather than call them all typos.
+     * Also `undefined` while a lazily registered state model is not loaded yet,
+     * for the same reason: nothing is known, so nothing is a typo.
+     *
+     * This is the set `withLaunchInput`'s partition reads off the same two
+     * declarations, published for the surfaces that never build a view snapshot —
+     * a session spec launches straight through `LaunchView-<type>`.
+     */
+    get acceptedKeys(): string[] | undefined;
+    get isStateModelLoaded(): boolean;
+    loadStateModel(): Promise<IAnyModelType>;
+    extendStateModel(extend: (stateModel: IAnyModelType) => IAnyModelType): void;
     addDisplayType(display: DisplayType): void;
 }
 export {};

package/esm/pluggableElementTypes/ViewType.js

@@ -1,17 +1,97 @@
-import PluggableElementBase from "./PluggableElementBase.js";
+import PluggableElementBase from './PluggableElementBase.js';
 export default class ViewType extends PluggableElementBase {
     ReactComponent;
-    stateModel;
+    loadedStateModel;
+    // Non-optional because nearly every reader holds a view instance, which
+    // implies the model is loaded; code that can run before any instance exists
+    // (session preloading, pruning, union membership) must check
+    // isStateModelLoaded first.
+    get stateModel() {
+        return this.loadedStateModel;
+    }
+    // named `stateModel` + `Loader` because pluggableMstType and
+    // pruneUnbuildableNodes probe `${fieldName}Loader` generically
+    stateModelLoader;
+    stateModelPromise;
+    pendingStateModelExtensions = [];
+    // What `withLaunchInput` partitioned out of this view's snapshots, published
+    // beside the model so an out-of-tree plugin, the doc generator and the
+    // validator read one declaration rather than each keeping a list.
+    launchKeys;
     displayTypes = [];
     viewMetadata = {};
+    // extendedName can be used for when you extend a given view type, and want
+    // to register all of that view types displays to yourself
+    //
+    // e.g. you create a linear-genome-view subtype, and want all the tracks that
+    // are compatible display types for the linear-genome-view to be compatible
+    // with your type also (without this, display types are only registered to a
+    // single view type)
     extendedName;
     constructor(stuff) {
         super(stuff);
         this.ReactComponent = stuff.ReactComponent;
-        this.viewMetadata = stuff.viewMetadata || {};
-        this.stateModel = stuff.stateModel;
+        this.viewMetadata = stuff.viewMetadata ?? {};
+        if (typeof stuff.stateModel === 'function') {
+            this.stateModelLoader = stuff.stateModel;
+        }
+        else {
+            this.loadedStateModel = stuff.stateModel;
+        }
+        this.launchKeys = stuff.launchKeys;
         this.extendedName = stuff.extendedName;
     }
+    /**
+     * Every key this view accepts written on the view object — its declared MST
+     * properties plus the launch keys above. `undefined` for a view that
+     * registers none: nothing there says which of its launcher's arguments are
+     * settings, so a caller must classify nothing rather than call them all typos.
+     * Also `undefined` while a lazily registered state model is not loaded yet,
+     * for the same reason: nothing is known, so nothing is a typo.
+     *
+     * This is the set `withLaunchInput`'s partition reads off the same two
+     * declarations, published for the surfaces that never build a view snapshot —
+     * a session spec launches straight through `LaunchView-<type>`.
+     */
+    get acceptedKeys() {
+        const properties = this.loadedStateModel?.properties;
+        return this.launchKeys && properties
+            ? [
+                ...Object.keys(properties),
+                ...Object.keys(this.launchKeys.keys),
+                ...this.launchKeys.passThrough,
+            ]
+            : undefined;
+    }
+    get isStateModelLoaded() {
+        return this.loadedStateModel !== undefined;
+    }
+    loadStateModel() {
+        if (this.loadedStateModel !== undefined) {
+            return Promise.resolve(this.loadedStateModel);
+        }
+        if (!this.stateModelLoader) {
+            throw new Error(`view type ${this.name} has neither a state model nor a loader`);
+        }
+        this.stateModelPromise ??= this.stateModelLoader().then(loaded => {
+            let stateModel = loaded;
+            for (const extend of this.pendingStateModelExtensions) {
+                stateModel = extend(stateModel);
+            }
+            this.pendingStateModelExtensions = [];
+            this.loadedStateModel = stateModel;
+            return stateModel;
+        });
+        return this.stateModelPromise;
+    }
+    extendStateModel(extend) {
+        if (this.loadedStateModel !== undefined) {
+            this.loadedStateModel = extend(this.loadedStateModel);
+        }
+        else {
+            this.pendingStateModelExtensions.push(extend);
+        }
+    }
     addDisplayType(display) {
         this.displayTypes.push(display);
     }

package/esm/pluggableElementTypes/WidgetType.d.ts

@@ -1,8 +1,8 @@
-import type { ComponentType, LazyExoticComponent } from 'react';
-import type React from 'react';
 import PluggableElementBase from './PluggableElementBase.ts';
 import type { AnyConfigurationSchemaType } from '../configuration/index.ts';
 import type { IAnyModelType, IAnyStateTreeNode } from '@jbrowse/mobx-state-tree';
+import type { ComponentType, LazyExoticComponent } from 'react';
+import type React from 'react';
 type WidgetComponentType = LazyExoticComponent<React.FC<any>> | React.FC<any>;
 type HeadingComponentType = ComponentType<{
     model: IAnyStateTreeNode;

package/esm/pluggableElementTypes/WidgetType.js

@@ -1,4 +1,4 @@
-import PluggableElementBase from "./PluggableElementBase.js";
+import PluggableElementBase from './PluggableElementBase.js';
 export default class WidgetType extends PluggableElementBase {
     heading;
     configSchema;

package/esm/pluggableElementTypes/addMenuItems.d.ts

@@ -0,0 +1,87 @@
+import type PluginManager from '../PluginManager.ts';
+import type { DisplayTypeName, DisplayTypeRegistry, ViewTypeName, ViewTypeRegistry } from '../PluginManager.ts';
+import type { MenuItem } from '../ui/MenuTypes.ts';
+import type { IAnyType, Instance } from '@jbrowse/mobx-state-tree';
+/**
+ * The instance a registry entry's state model produces. The registries are
+ * declared empty here and filled by module augmentation, so inside this package
+ * every one of these resolves to `never` — see {@link extendViewType} for why
+ * that is fine and what the caller gets instead.
+ */
+type ModelOf<T> = T extends IAnyType ? Instance<T> : never;
+/**
+ * The methods on a model that return a menu. Derived from the model rather than
+ * listed, which is what makes a renamed or retired method a compile error at
+ * the call site: there are six of them across views and displays (`menuItems`,
+ * `trackMenuItems`, `contextMenuItems`, `rubberBandMenuItems`,
+ * `rubberBandLaunchMenuItems`, `highlightMenuItems`), they are a convention
+ * rather than one declared interface, and a contribution to a name the model no
+ * longer has is otherwise silent.
+ *
+ * Given several names, `M` arrives as the union of their models and `keyof M`
+ * is what they share, so a menu only one of them has is a compile error rather
+ * than a `self[menu]` that is undefined on the others.
+ */
+type MenuMethodName<M> = {
+    [K in keyof M]: M[K] extends (...args: never[]) => MenuItem[] ? K : never;
+}[keyof M];
+/**
+ * What a contributor is handed: the model, plus whatever the menu method itself
+ * takes (`highlightMenuItems` gets the highlight). Returning `undefined` adds
+ * nothing, which is how a contribution scoped to some state opts out.
+ */
+type MenuItemsCallback<M, K extends keyof M> = (model: M, ...args: M[K] extends (...args: infer A) => unknown ? A : never) => MenuItem | MenuItem[] | undefined;
+interface MenuItemsOptions<M, K extends keyof M> {
+    /** which menu to add to */
+    menu: K;
+    /**
+     * a submenu label to collect the items under, e.g. `LAUNCH_LABEL`. The
+     * submenu is created once and shared, so several plugins naming the same
+     * group land in one place rather than each adding a top-level row
+     */
+    group?: string;
+    items: MenuItemsCallback<M, K>;
+}
+/**
+ * Add items to a menu on a view type belonging to another plugin, e.g. an "open
+ * a synteny view on this locus" entry on the linear genome view. Pass an array
+ * to contribute the same items to several types at once.
+ *
+ * Prefer this to extending the state model by hand. The model is the right seam
+ * — `menuItems()` is called from seven pieces of view chrome, and only the model
+ * reaches all of them — but writing the extension out means `stateModel.views`,
+ * capturing the previous method, spreading it, and remembering to return the
+ * whole array. Each of those is silent when it goes wrong, and the middle one
+ * costs every plugin registered earlier its items.
+ *
+ * ```ts
+ * addViewMenuItems(pluginManager, 'LinearGenomeView', {
+ *   menu: 'rubberBandLaunchMenuItems',
+ *   items: self => ({ label: 'Consensus sequence', onClick: () => {} }),
+ * })
+ * ```
+ *
+ * A contribution needing state or actions of its own is still a model
+ * extension: use {@link extendViewType} and add the menu items in the same
+ * `.views` block, so the items and the actions they call stay together.
+ */
+export declare function addViewMenuItems<N extends ViewTypeName, K extends MenuMethodName<ModelOf<ViewTypeRegistry[N]>>>(pluginManager: PluginManager, name: N | readonly N[], options: MenuItemsOptions<ModelOf<ViewTypeRegistry[N]>, K>): void;
+/**
+ * Add items to a menu on a display type belonging to another plugin, e.g. an
+ * "open this read in a dotplot" entry on the alignments display's context menu.
+ * See {@link addViewMenuItems}; the name is checked against
+ * `DisplayTypeRegistry`.
+ *
+ * ```ts
+ * addDisplayMenuItems(pluginManager, 'LinearAlignmentsDisplay', {
+ *   menu: 'contextMenuItems',
+ *   group: LAUNCH_LABEL,
+ *   items: self =>
+ *     self.contextMenuFeatureId === undefined
+ *       ? undefined
+ *       : { label: 'Dotplot of read vs ref', onClick: () => {} },
+ * })
+ * ```
+ */
+export declare function addDisplayMenuItems<N extends DisplayTypeName, K extends MenuMethodName<ModelOf<DisplayTypeRegistry[N]>>>(pluginManager: PluginManager, name: N | readonly N[], options: MenuItemsOptions<ModelOf<DisplayTypeRegistry[N]>, K>): void;
+export {};

package/esm/pluggableElementTypes/addMenuItems.js

@@ -0,0 +1,82 @@
+import { pushIntoSubMenu } from '../ui/launchViewMenu.js';
+import { extendDisplayType, extendViewType } from './extendElementType.js';
+// The shared fold. Both entry points are thin wrappers rather than overloads of
+// one function: with overloads, a `menu` the model does not have stops matching
+// the view signature, falls through to the display one, and reports as "'view'
+// does not exist in type …" — an error about the wrong parameter, for a mistake
+// this helper exists to name precisely.
+function menuExtension(menu, group, items) {
+    return (stateModel) => stateModel.views((self) => {
+        const superMenu = self[menu];
+        return {
+            // Copied rather than pushed into: `group` reaches inside an item the
+            // method before us built, and the array it came from is this call's
+            // to change, not one an earlier caller is still holding.
+            [menu](...args) {
+                const built = [...superMenu(...args)];
+                const contributed = items(self, ...args);
+                if (contributed !== undefined) {
+                    for (const item of Array.isArray(contributed)
+                        ? contributed
+                        : [contributed]) {
+                        if (group === undefined) {
+                            built.push(item);
+                        }
+                        else {
+                            pushIntoSubMenu(built, group, item);
+                        }
+                    }
+                }
+                return built;
+            },
+        };
+    });
+}
+/**
+ * Add items to a menu on a view type belonging to another plugin, e.g. an "open
+ * a synteny view on this locus" entry on the linear genome view. Pass an array
+ * to contribute the same items to several types at once.
+ *
+ * Prefer this to extending the state model by hand. The model is the right seam
+ * — `menuItems()` is called from seven pieces of view chrome, and only the model
+ * reaches all of them — but writing the extension out means `stateModel.views`,
+ * capturing the previous method, spreading it, and remembering to return the
+ * whole array. Each of those is silent when it goes wrong, and the middle one
+ * costs every plugin registered earlier its items.
+ *
+ * ```ts
+ * addViewMenuItems(pluginManager, 'LinearGenomeView', {
+ *   menu: 'rubberBandLaunchMenuItems',
+ *   items: self => ({ label: 'Consensus sequence', onClick: () => {} }),
+ * })
+ * ```
+ *
+ * A contribution needing state or actions of its own is still a model
+ * extension: use {@link extendViewType} and add the menu items in the same
+ * `.views` block, so the items and the actions they call stay together.
+ */
+export function addViewMenuItems(pluginManager, name, options) {
+    const { menu, group, items } = options;
+    extendViewType(pluginManager, name, menuExtension(menu, group, items));
+}
+/**
+ * Add items to a menu on a display type belonging to another plugin, e.g. an
+ * "open this read in a dotplot" entry on the alignments display's context menu.
+ * See {@link addViewMenuItems}; the name is checked against
+ * `DisplayTypeRegistry`.
+ *
+ * ```ts
+ * addDisplayMenuItems(pluginManager, 'LinearAlignmentsDisplay', {
+ *   menu: 'contextMenuItems',
+ *   group: LAUNCH_LABEL,
+ *   items: self =>
+ *     self.contextMenuFeatureId === undefined
+ *       ? undefined
+ *       : { label: 'Dotplot of read vs ref', onClick: () => {} },
+ * })
+ * ```
+ */
+export function addDisplayMenuItems(pluginManager, name, options) {
+    const { menu, group, items } = options;
+    extendDisplayType(pluginManager, name, menuExtension(menu, group, items));
+}

package/esm/pluggableElementTypes/extendElementType.d.ts

@@ -0,0 +1,30 @@
+import type PluginManager from '../PluginManager.ts';
+import type { DisplayTypeName, DisplayTypeRegistry, ViewTypeName, ViewTypeRegistry } from '../PluginManager.ts';
+import type { IAnyModelType } from '@jbrowse/mobx-state-tree';
+/**
+ * Replace a view type's state model with an extended one, e.g. to add a menu
+ * item to `LinearGenomeView`. Pass an array to extend several at once, which is
+ * how a contribution reaches a family: the tree spells a display family as a
+ * shared mixin set rather than a chain, so there is no parent to name — see
+ * `reference/REJECTED_IDEAS.md`, "Give a pluggable element an `extendsType`".
+ *
+ * `Core-extendPluggableElement` fires for every pluggable element there is —
+ * adapters, widgets, RPC methods, all of them — so a callback written against
+ * it directly has to match the name, convince TypeScript the element is the
+ * kind that name implies, and remember to return the element. The middle one
+ * has no honest answer at the call site, which is why the two plugins that
+ * tried both landed on a type guard asserting `elt is DisplayType` from a
+ * string compare, which would go on asserting it if the name ever belonged to
+ * something else.
+ *
+ * Here the group is checked rather than asserted — it comes from
+ * `addElementType`, which knew it all along — and the name is checked against
+ * `ViewTypeRegistry`, so the state model arrives typed and a rename is a
+ * compile error rather than an extension that quietly stops applying.
+ */
+export declare function extendViewType<N extends ViewTypeName>(pluginManager: PluginManager, name: N | readonly N[], extend: (stateModel: ViewTypeRegistry[N]) => IAnyModelType): void;
+/**
+ * Replace a display type's state model with an extended one. See
+ * {@link extendViewType}; the name is checked against `DisplayTypeRegistry`.
+ */
+export declare function extendDisplayType<N extends DisplayTypeName>(pluginManager: PluginManager, name: N | readonly N[], extend: (stateModel: DisplayTypeRegistry[N]) => IAnyModelType): void;

package/esm/pluggableElementTypes/extendElementType.js

@@ -0,0 +1,73 @@
+// The one cast, in one place, named. `extend` is written by a caller against a
+// registry entry; this package cannot name that entry (see extendViewType), so
+// the callback is re-read as taking the base model type to call it.
+function widen(extend) {
+    return extend;
+}
+// Built once per registration rather than per element: the point fires for
+// every pluggable element there is, and every callback registered on it runs
+// for each one.
+function namesOf(name) {
+    return new Set(typeof name === 'string' ? [name] : name);
+}
+/**
+ * Replace a view type's state model with an extended one, e.g. to add a menu
+ * item to `LinearGenomeView`. Pass an array to extend several at once, which is
+ * how a contribution reaches a family: the tree spells a display family as a
+ * shared mixin set rather than a chain, so there is no parent to name — see
+ * `reference/REJECTED_IDEAS.md`, "Give a pluggable element an `extendsType`".
+ *
+ * `Core-extendPluggableElement` fires for every pluggable element there is —
+ * adapters, widgets, RPC methods, all of them — so a callback written against
+ * it directly has to match the name, convince TypeScript the element is the
+ * kind that name implies, and remember to return the element. The middle one
+ * has no honest answer at the call site, which is why the two plugins that
+ * tried both landed on a type guard asserting `elt is DisplayType` from a
+ * string compare, which would go on asserting it if the name ever belonged to
+ * something else.
+ *
+ * Here the group is checked rather than asserted — it comes from
+ * `addElementType`, which knew it all along — and the name is checked against
+ * `ViewTypeRegistry`, so the state model arrives typed and a rename is a
+ * compile error rather than an extension that quietly stops applying.
+ */
+export function extendViewType(pluginManager, name, extend) {
+    const names = namesOf(name);
+    pluginManager.addToExtensionPoint('Core-extendPluggableElement', (element, props) => {
+        if (props.group === 'view' && names.has(element.name)) {
+            // The group check established this element is a ViewType, and the
+            // registry says which one, so the read is proven. The body still works
+            // in `IAnyModelType`: `ViewTypeRegistry` is declared empty here and
+            // filled by module augmentation, so inside this package `ViewTypeName`
+            // is `never` and `ViewTypeRegistry[N]` with it — a value of that type
+            // cannot be produced or consumed, and compiling core alone fails on
+            // both. The precise type is what the *caller* gets, which is the whole
+            // point of the signature; widening it once here costs nothing, since
+            // the only operation is handing the model to `extend` and storing what
+            // comes back.
+            //
+            // Routed through extendStateModel rather than assigning `.stateModel`
+            // directly so a view registered with a lazy loader queues the
+            // extension and composes it when the loader resolves.
+            const view = element;
+            view.extendStateModel(widen(extend));
+        }
+        return element;
+    });
+}
+/**
+ * Replace a display type's state model with an extended one. See
+ * {@link extendViewType}; the name is checked against `DisplayTypeRegistry`.
+ */
+export function extendDisplayType(pluginManager, name, extend) {
+    const names = namesOf(name);
+    pluginManager.addToExtensionPoint('Core-extendPluggableElement', (element, props) => {
+        if (props.group === 'display' && names.has(element.name)) {
+            // widened for the reason in extendViewType; routed through
+            // extendStateModel so a lazy registration queues the extension
+            const display = element;
+            display.extendStateModel(widen(extend));
+        }
+        return element;
+    });
+}

package/esm/pluggableElementTypes/index.d.ts

@@ -2,26 +2,26 @@ import type AdapterType from './AdapterType.ts';
 import type AddTrackWorkflowType from './AddTrackWorkflowType.ts';
 import type ConnectionType from './ConnectionType.ts';
 import type DisplayType from './DisplayType.ts';
-import type GlyphType from './GlyphType.ts';
 import type InternetAccountType from './InternetAccountType.ts';
 import type RpcMethodType from './RpcMethodType.ts';
 import type TextSearchAdapterType from './TextSearchAdapterType.ts';
 import type TrackType from './TrackType.ts';
 import type ViewType from './ViewType.ts';
 import type WidgetType from './WidgetType.ts';
-import type RendererType from './renderers/RendererType.tsx';
-export * from './renderers/index.ts';
-export * from './models/index.ts';
-export type PluggableElementType = AdapterType | ConnectionType | RendererType | WidgetType | TrackType | DisplayType | ViewType | RpcMethodType | InternetAccountType | TextSearchAdapterType | AddTrackWorkflowType | GlyphType;
+export { BaseConnectionModelFactory, BaseDisplay, type BaseDisplayModel, type BaseDisplayStateModel, BaseInternetAccountConfig, type BaseInternetAccountModel, type BaseInternetAccountStateModel, type BaseTrackConfig, type BaseTrackModel, type BaseTrackStateModel, BaseViewModel, type DisplayModel, type FileTypeExporter, HighlightsMixin, type IBaseViewModel, InternetAccount, addDisplayConfigMigration, baseConnectionConfig, createBaseTrackConfig, createBaseTrackModel, preprocessTrackConfigSnapshot, type TrackConfigSnapshot, trackConfigActions, } from './models/index.ts';
+export type PluggableElementType = AdapterType | ConnectionType | WidgetType | TrackType | DisplayType | ViewType | RpcMethodType | InternetAccountType | TextSearchAdapterType | AddTrackWorkflowType;
+export { extendDisplayType, extendViewType } from './extendElementType.ts';
+export { addDisplayMenuItems, addViewMenuItems } from './addMenuItems.ts';
 export { default as AdapterType } from './AdapterType.ts';
-export { default as RendererType } from './renderers/RendererType.tsx';
 export { default as ConnectionType } from './ConnectionType.ts';
 export { default as TrackType } from './TrackType.ts';
 export { default as WidgetType } from './WidgetType.ts';
 export { default as ViewType } from './ViewType.ts';
 export { default as DisplayType } from './DisplayType.ts';
 export { default as InternetAccountType } from './InternetAccountType.ts';
-export { default as GlyphType } from './GlyphType.ts';
 export { default as RpcMethodType } from './RpcMethodType.ts';
+export { default as RpcMethodTypeWithRenameRegion } from './RpcMethodTypeWithRenameRegion.ts';
+export { default as RpcMethodTypeWithRenameRegions } from './RpcMethodTypeWithRenameRegions.ts';
 export { default as AddTrackWorkflowType } from './AddTrackWorkflowType.ts';
+export type { AddTrackWorkflowCategory } from './AddTrackWorkflowType.ts';
 export { default as TextSearchAdapterType } from './TextSearchAdapterType.ts';

package/esm/pluggableElementTypes/index.js

@@ -1,14 +1,24 @@
-export * from "./renderers/index.js";
-export * from "./models/index.js";
-export { default as AdapterType } from "./AdapterType.js";
-export { default as RendererType } from "./renderers/RendererType.js";
-export { default as ConnectionType } from "./ConnectionType.js";
-export { default as TrackType } from "./TrackType.js";
-export { default as WidgetType } from "./WidgetType.js";
-export { default as ViewType } from "./ViewType.js";
-export { default as DisplayType } from "./DisplayType.js";
-export { default as InternetAccountType } from "./InternetAccountType.js";
-export { default as GlyphType } from "./GlyphType.js";
-export { default as RpcMethodType } from "./RpcMethodType.js";
-export { default as AddTrackWorkflowType } from "./AddTrackWorkflowType.js";
-export { default as TextSearchAdapterType } from "./TextSearchAdapterType.js";
+export { BaseConnectionModelFactory, BaseDisplay, BaseInternetAccountConfig, BaseViewModel, HighlightsMixin, InternetAccount, addDisplayConfigMigration, baseConnectionConfig, createBaseTrackConfig, createBaseTrackModel, preprocessTrackConfigSnapshot, trackConfigActions, } from './models/index.js';
+export { extendDisplayType, extendViewType } from './extendElementType.js';
+export { addDisplayMenuItems, addViewMenuItems } from './addMenuItems.js';
+export { default as AdapterType } from './AdapterType.js';
+export { default as ConnectionType } from './ConnectionType.js';
+export { default as TrackType } from './TrackType.js';
+export { default as WidgetType } from './WidgetType.js';
+export { default as ViewType } from './ViewType.js';
+export { default as DisplayType } from './DisplayType.js';
+export { default as InternetAccountType } from './InternetAccountType.js';
+export { default as RpcMethodType } from './RpcMethodType.js';
+// The two region-renaming bases, which nearly every RPC method that takes a
+// viewport wants — without them an external plugin deep-imports the file and
+// bundles its own copy, which is only harmless because RPC methods are keyed by
+// name (PluginManager.rpcMethods) and nothing does an instanceof.
+// `RpcMethodTypeWithFiltersAndRenameRegions` is deliberately not here: it pulls
+// in `renderers/util/serializableFilterChain`, and RFC-001 §9 deletes
+// `pluggableElementTypes/renderers/*` after the legacy renderer migration. This
+// barrel is served as ABI, so exporting it would pin a directory we intend to
+// remove.
+export { default as RpcMethodTypeWithRenameRegion } from './RpcMethodTypeWithRenameRegion.js';
+export { default as RpcMethodTypeWithRenameRegions } from './RpcMethodTypeWithRenameRegions.js';
+export { default as AddTrackWorkflowType } from './AddTrackWorkflowType.js';
+export { default as TextSearchAdapterType } from './TextSearchAdapterType.js';