Skip to content

finding(docs): core/app-schema.mdx's "Global Actions" snippet imports the wrong same-named MenuItem #6692

Description

@os-sales

Found while implementing #6523 / #6346 (the overlay.tsMenuItem discriminated-union +
onClick fix). Filed unassigned and out of both cards' fence — this is a pre-existing,
unrelated docs/type-naming collision, not something either ruling's diff touches.

What was measured, at c75b928e6

content/docs/core/app-schema.mdx's ## Global Actions section has a real, compiled
ts fence (unlike the plaintext "Schema" blocks elsewhere on this same page):

importtype{MenuItem}from'@object-ui/types';interfaceAppAction{
...
items?: MenuItem[];// For type='dropdown' or 'user'
...
}

import type { MenuItem } from '@object-ui/types' resolves to the overlayMenuItem
(packages/types/src/overlay.ts, re-exported at index.ts:255 under the bare name
MenuItem) — the discriminated union shared by ui:dropdown-menu/ui:context-menu/
ui:menubar, which #6523 just reshaped.

But the realAppAction.items field — packages/types/src/app.ts:728 — is declared
inside app.ts itself, so MenuItem[] there resolves to app.ts's own localMenuItem
(app.ts:461), a structurally different, legacy navigation-item shape (type?: 'item' | 'group' | 'separator', path, href, badge, hidden — none of which the overlay
MenuItem declares). The barrel re-exports app.ts's version under the renamed
AppMenuItem (index.ts:59) specifically to avoid this collision — but the docs snippet
imports the bare, unrenamed name, so it silently picks up the WRONG same-named type.

Confirmed this is not new: app.ts's own MenuItem and overlay.ts's MenuItem have
always been structurally different (this predates #6523's union split — before it, the
overlay MenuItem was still a single object with label: string required, icon,
disabled, onClick, shortcut, children, separator?: boolean, none of which match
app.ts's type/path/href/badge/hidden shape either).

Why this doesn't block #6523/#6346

The snippet is a bare type reference (items?: MenuItem[]), not an object literal that
instantiates the shape — so it compiles under check-doc-snippet-types.mjs regardless of
which MenuItem it actually resolves to, and #6523's union split doesn't change whether it
compiles. Confirmed unaffected by grepping the diff: the snippet's own text is untouched by
either card.

The open question

Two candidate fixes, not adjudicated here:

  • A — the snippet's import is simply wrong; change it to import type { MenuItem as AppMenuItem } from '@object-ui/types'; (or import from '@object-ui/types''s already-exported
    AppMenuItem name directly) so the reader compiles against the type that's actually there.
  • BAppAction.items itself is questionable: dropdown/user toolbar actions plausibly
    WANT the richer overlay MenuItem (icon, onClick, shortcut, submenu children, divider) more
    than the legacy nav-item shape (path/href/badge) app.ts gives them today — worth
    checking whether header-bar.tsx (the renderer consuming AppAction.items) actually reads
    app.ts's fields or the overlay ones before choosing.

Whichever way, this is a genuine decision (which MenuItemAppAction.items should mean),
not a mechanical fix, so it doesn't qualify for the bounded in-place-fix exemption on the PR
that found it.

Refs: #6523 · #6346 (found while implementing, unrelated to either ruling).

Metadata

Metadata

Assignees

Labels

documentationImprovements or additions to documentationdomain:uiobjectui ui stream: fix lands on the published library or apps — objectui execution seatpriority:p2

Type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions

    , 'i'); if (__m === '*' || __re.test(location.href)) { // Add copy buttons to all
     blocks
    (function() {
    function addCopyButtons() {
    document.querySelectorAll('pre code').forEach(function(codeBlock) {
    if (codeBlock.parentElement.hasAttribute('data-copy-added')) return;
    codeBlock.parentElement.setAttribute('data-copy-added', 'true');
    var btn = document.createElement('button');
    btn.textContent = 'Copy';
    btn.style.cssText = 'position:absolute;top:4px;right:4px;padding:2px 8px;font-size:11px;background:#4ecdc4;border:none;border-radius:4px;color:#1a1a2e;cursor:pointer;opacity:0.7;transition:opacity 0.2s;';
    btn.onmouseover = function() { this.style.opacity = '1'; };
    btn.onmouseout = function() { this.style.opacity = '0.7'; };
    btn.onclick = function() {
    navigator.clipboard.writeText(codeBlock.textContent).then(function() {
    btn.textContent = 'Copied!';
    setTimeout(function() { btn.textContent = 'Copy'; }, 1500);
    });
    };
    codeBlock.parentElement.style.position = 'relative';
    codeBlock.parentElement.appendChild(btn);
    });
    }
    addCopyButtons();
    // Re-run on dynamic content
    var observer = new MutationObserver(addCopyButtons);
    observer.observe(document.body, { childList: true, subtree: true });
    })();
    }
    } catch(__e) { console.warn('[Userscript:Add Copy Buttons to Code Blocks]', __e); }
    })();
    (function(){
    try {
    var __m = "github.com";
    var __re = new RegExp('^' + "github\\.com" + '
    finding(docs): core/app-schema.mdx's "Global Actions" snippet imports the wrong same-named `MenuItem` · Issue #6692 · objectstack-ai/objectui · GitHub
    Skip to content

    finding(docs): core/app-schema.mdx's "Global Actions" snippet imports the wrong same-named MenuItem #6692

    Description

    @os-sales

    Found while implementing #6523 / #6346 (the overlay.tsMenuItem discriminated-union +
    onClick fix). Filed unassigned and out of both cards' fence — this is a pre-existing,
    unrelated docs/type-naming collision, not something either ruling's diff touches.

    What was measured, at c75b928e6

    content/docs/core/app-schema.mdx's ## Global Actions section has a real, compiled
    ts fence (unlike the plaintext "Schema" blocks elsewhere on this same page):

    importtype{MenuItem}from'@object-ui/types';interfaceAppAction{
    ...
    items?: MenuItem[];// For type='dropdown' or 'user'
    ...
    }

    import type { MenuItem } from '@object-ui/types' resolves to the overlayMenuItem
    (packages/types/src/overlay.ts, re-exported at index.ts:255 under the bare name
    MenuItem) — the discriminated union shared by ui:dropdown-menu/ui:context-menu/
    ui:menubar, which #6523 just reshaped.

    But the realAppAction.items field — packages/types/src/app.ts:728 — is declared
    inside app.ts itself, so MenuItem[] there resolves to app.ts's own localMenuItem
    (app.ts:461), a structurally different, legacy navigation-item shape (type?: 'item' | 'group' | 'separator', path, href, badge, hidden — none of which the overlay
    MenuItem declares). The barrel re-exports app.ts's version under the renamed
    AppMenuItem (index.ts:59) specifically to avoid this collision — but the docs snippet
    imports the bare, unrenamed name, so it silently picks up the WRONG same-named type.

    Confirmed this is not new: app.ts's own MenuItem and overlay.ts's MenuItem have
    always been structurally different (this predates #6523's union split — before it, the
    overlay MenuItem was still a single object with label: string required, icon,
    disabled, onClick, shortcut, children, separator?: boolean, none of which match
    app.ts's type/path/href/badge/hidden shape either).

    Why this doesn't block #6523/#6346

    The snippet is a bare type reference (items?: MenuItem[]), not an object literal that
    instantiates the shape — so it compiles under check-doc-snippet-types.mjs regardless of
    which MenuItem it actually resolves to, and #6523's union split doesn't change whether it
    compiles. Confirmed unaffected by grepping the diff: the snippet's own text is untouched by
    either card.

    The open question

    Two candidate fixes, not adjudicated here:

    • A — the snippet's import is simply wrong; change it to import type { MenuItem as AppMenuItem } from '@object-ui/types'; (or import from '@object-ui/types''s already-exported
      AppMenuItem name directly) so the reader compiles against the type that's actually there.
    • BAppAction.items itself is questionable: dropdown/user toolbar actions plausibly
      WANT the richer overlay MenuItem (icon, onClick, shortcut, submenu children, divider) more
      than the legacy nav-item shape (path/href/badge) app.ts gives them today — worth
      checking whether header-bar.tsx (the renderer consuming AppAction.items) actually reads
      app.ts's fields or the overlay ones before choosing.

    Whichever way, this is a genuine decision (which MenuItemAppAction.items should mean),
    not a mechanical fix, so it doesn't qualify for the bounded in-place-fix exemption on the PR
    that found it.

    Refs: #6523 · #6346 (found while implementing, unrelated to either ruling).

    Metadata

    Metadata

    Assignees

    Labels

    documentationImprovements or additions to documentationdomain:uiobjectui ui stream: fix lands on the published library or apps — objectui execution seatpriority:p2

    Type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions

      , 'i'); if (__m === '*' || __re.test(location.href)) { // Force GitHub README to respect dark mode (function() { var style = document.createElement('style'); style.textContent = ' .markdown-body { color-scheme: dark light; } .markdown-body pre { background: #161b22 !important; } .markdown-body code { background: rgba(110, 118, 129, 0.4) !important; } .markdown-body table th, .markdown-body table td { border-color: #30363d !important; } .markdown-body img { background: #0d1117; } .markdown-body blockquote { border-left-color: #8b949e; } .markdown-body hr { border-color: #30363d; } '; document.head.appendChild(style); })(); } } catch(__e) { console.warn('[Userscript:GitHub Dark Mode README Fix]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + ' finding(docs): core/app-schema.mdx's "Global Actions" snippet imports the wrong same-named `MenuItem` · Issue #6692 · objectstack-ai/objectui · GitHub
      Skip to content

      finding(docs): core/app-schema.mdx's "Global Actions" snippet imports the wrong same-named MenuItem #6692

      Description

      @os-sales

      Found while implementing #6523 / #6346 (the overlay.tsMenuItem discriminated-union +
      onClick fix). Filed unassigned and out of both cards' fence — this is a pre-existing,
      unrelated docs/type-naming collision, not something either ruling's diff touches.

      What was measured, at c75b928e6

      content/docs/core/app-schema.mdx's ## Global Actions section has a real, compiled
      ts fence (unlike the plaintext "Schema" blocks elsewhere on this same page):

      importtype{MenuItem}from'@object-ui/types';interfaceAppAction{
      ...
      items?: MenuItem[];// For type='dropdown' or 'user'
      ...
      }

      import type { MenuItem } from '@object-ui/types' resolves to the overlayMenuItem
      (packages/types/src/overlay.ts, re-exported at index.ts:255 under the bare name
      MenuItem) — the discriminated union shared by ui:dropdown-menu/ui:context-menu/
      ui:menubar, which #6523 just reshaped.

      But the realAppAction.items field — packages/types/src/app.ts:728 — is declared
      inside app.ts itself, so MenuItem[] there resolves to app.ts's own localMenuItem
      (app.ts:461), a structurally different, legacy navigation-item shape (type?: 'item' | 'group' | 'separator', path, href, badge, hidden — none of which the overlay
      MenuItem declares). The barrel re-exports app.ts's version under the renamed
      AppMenuItem (index.ts:59) specifically to avoid this collision — but the docs snippet
      imports the bare, unrenamed name, so it silently picks up the WRONG same-named type.

      Confirmed this is not new: app.ts's own MenuItem and overlay.ts's MenuItem have
      always been structurally different (this predates #6523's union split — before it, the
      overlay MenuItem was still a single object with label: string required, icon,
      disabled, onClick, shortcut, children, separator?: boolean, none of which match
      app.ts's type/path/href/badge/hidden shape either).

      Why this doesn't block #6523/#6346

      The snippet is a bare type reference (items?: MenuItem[]), not an object literal that
      instantiates the shape — so it compiles under check-doc-snippet-types.mjs regardless of
      which MenuItem it actually resolves to, and #6523's union split doesn't change whether it
      compiles. Confirmed unaffected by grepping the diff: the snippet's own text is untouched by
      either card.

      The open question

      Two candidate fixes, not adjudicated here:

      • A — the snippet's import is simply wrong; change it to import type { MenuItem as AppMenuItem } from '@object-ui/types'; (or import from '@object-ui/types''s already-exported
        AppMenuItem name directly) so the reader compiles against the type that's actually there.
      • BAppAction.items itself is questionable: dropdown/user toolbar actions plausibly
        WANT the richer overlay MenuItem (icon, onClick, shortcut, submenu children, divider) more
        than the legacy nav-item shape (path/href/badge) app.ts gives them today — worth
        checking whether header-bar.tsx (the renderer consuming AppAction.items) actually reads
        app.ts's fields or the overlay ones before choosing.

      Whichever way, this is a genuine decision (which MenuItemAppAction.items should mean),
      not a mechanical fix, so it doesn't qualify for the bounded in-place-fix exemption on the PR
      that found it.

      Refs: #6523 · #6346 (found while implementing, unrelated to either ruling).

      Metadata

      Metadata

      Assignees

      Labels

      documentationImprovements or additions to documentationdomain:uiobjectui ui stream: fix lands on the published library or apps — objectui execution seatpriority:p2

      Type

      Projects

      No projects

        Milestone

        No milestone

        Relationships

        None yet

        Development

        No branches or pull requests

        Issue actions

        , 'i'); if (__m === '*' || __re.test(location.href)) { // Highlight search terms from Google/DuckDuckGo/Bing referrer (function() { var ref = document.referrer; var terms = []; if (ref.includes('google.com') || ref.includes('duckduckgo.com') || ref.includes('bing.com')) { var url = new URL(ref); var q = url.searchParams.get('q') || url.searchParams.get('p'); if (q) { terms = q.split(/\s+/).filter(function(t) { return t.length > 2; }); } } if (terms.length === 0) return; var style = document.createElement('style'); style.textContent = '.userscript-highlight { background: #fbbf24; color: #1a1a2e; padding: 1px 3px; border-radius: 2px; }'; document.head.appendChild(style); function highlight(node) { if (node.nodeType === 3) { // text node var text = node.textContent; var found = false; terms.forEach(function(term) { var regex = new RegExp('(' + term.replace(/[.*+?^${}()|[\]\\]/g, '\\') + ')', 'gi'); if (regex.test(text)) { found = true; var frag = document.createDocumentFragment(); var parts = text.split(regex); parts.forEach(function(part, i) { if (i % 2 === 0) { frag.appendChild(document.createTextNode(part)); } else { var span = document.createElement('span'); span.className = 'userscript-highlight'; span.textContent = part; frag.appendChild(span); } }); node.parentNode.replaceChild(frag, node); } }); } else if (node.nodeType === 1 && node.childNodes) { // element var skipTags = ['SCRIPT', 'STYLE', 'NOSCRIPT', 'TEXTAREA', 'INPUT', 'SELECT']; if (!skipTags.includes(node.tagName)) { Array.from(node.childNodes).forEach(highlight); } } } highlight(document.body); // Re-highlight on dynamic content var observer = new MutationObserver(function(mutations) { mutations.forEach(function(m) { m.addedNodes.forEach(function(node) { if (node.nodeType === 1 || node.nodeType === 3) highlight(node); }); }); }); observer.observe(document.body, { childList: true, subtree: true }); })(); } } catch(__e) { console.warn('[Userscript:Highlight Search Terms]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + ' finding(docs): core/app-schema.mdx's "Global Actions" snippet imports the wrong same-named `MenuItem` · Issue #6692 · objectstack-ai/objectui · GitHub
        Skip to content

        finding(docs): core/app-schema.mdx's "Global Actions" snippet imports the wrong same-named MenuItem #6692

        Description

        @os-sales

        Found while implementing #6523 / #6346 (the overlay.tsMenuItem discriminated-union +
        onClick fix). Filed unassigned and out of both cards' fence — this is a pre-existing,
        unrelated docs/type-naming collision, not something either ruling's diff touches.

        What was measured, at c75b928e6

        content/docs/core/app-schema.mdx's ## Global Actions section has a real, compiled
        ts fence (unlike the plaintext "Schema" blocks elsewhere on this same page):

        importtype{MenuItem}from'@object-ui/types';interfaceAppAction{
        ...
        items?: MenuItem[];// For type='dropdown' or 'user'
        ...
        }

        import type { MenuItem } from '@object-ui/types' resolves to the overlayMenuItem
        (packages/types/src/overlay.ts, re-exported at index.ts:255 under the bare name
        MenuItem) — the discriminated union shared by ui:dropdown-menu/ui:context-menu/
        ui:menubar, which #6523 just reshaped.

        But the realAppAction.items field — packages/types/src/app.ts:728 — is declared
        inside app.ts itself, so MenuItem[] there resolves to app.ts's own localMenuItem
        (app.ts:461), a structurally different, legacy navigation-item shape (type?: 'item' | 'group' | 'separator', path, href, badge, hidden — none of which the overlay
        MenuItem declares). The barrel re-exports app.ts's version under the renamed
        AppMenuItem (index.ts:59) specifically to avoid this collision — but the docs snippet
        imports the bare, unrenamed name, so it silently picks up the WRONG same-named type.

        Confirmed this is not new: app.ts's own MenuItem and overlay.ts's MenuItem have
        always been structurally different (this predates #6523's union split — before it, the
        overlay MenuItem was still a single object with label: string required, icon,
        disabled, onClick, shortcut, children, separator?: boolean, none of which match
        app.ts's type/path/href/badge/hidden shape either).

        Why this doesn't block #6523/#6346

        The snippet is a bare type reference (items?: MenuItem[]), not an object literal that
        instantiates the shape — so it compiles under check-doc-snippet-types.mjs regardless of
        which MenuItem it actually resolves to, and #6523's union split doesn't change whether it
        compiles. Confirmed unaffected by grepping the diff: the snippet's own text is untouched by
        either card.

        The open question

        Two candidate fixes, not adjudicated here:

        • A — the snippet's import is simply wrong; change it to import type { MenuItem as AppMenuItem } from '@object-ui/types'; (or import from '@object-ui/types''s already-exported
          AppMenuItem name directly) so the reader compiles against the type that's actually there.
        • BAppAction.items itself is questionable: dropdown/user toolbar actions plausibly
          WANT the richer overlay MenuItem (icon, onClick, shortcut, submenu children, divider) more
          than the legacy nav-item shape (path/href/badge) app.ts gives them today — worth
          checking whether header-bar.tsx (the renderer consuming AppAction.items) actually reads
          app.ts's fields or the overlay ones before choosing.

        Whichever way, this is a genuine decision (which MenuItemAppAction.items should mean),
        not a mechanical fix, so it doesn't qualify for the bounded in-place-fix exemption on the PR
        that found it.

        Refs: #6523 · #6346 (found while implementing, unrelated to either ruling).

        Metadata

        Metadata

        Assignees

        Labels

        documentationImprovements or additions to documentationdomain:uiobjectui ui stream: fix lands on the published library or apps — objectui execution seatpriority:p2

        Type

        Projects

        No projects

          Milestone

          No milestone

          Relationships

          None yet

          Development

          No branches or pull requests

          Issue actions

          , 'i'); if (__m === '*' || __re.test(location.href)) { // Strip utm_, fbclid, gclid, etc. from all links on page (function() { var trackingParams = ['utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content', 'fbclid', 'gclid', 'dclid', 'msclkid', 'yclid', 'ref', 'ref_src', 'source', 'medium', 'campaign']; function cleanUrl(url) { try { var u = new URL(url, window.location.origin); var changed = false; trackingParams.forEach(function(p) { if (u.searchParams.has(p)) { u.searchParams.delete(p); changed = true; } }); return changed ? u.toString() : url; } catch (e) { return url; } } function cleanLinks() { document.querySelectorAll('a[href]').forEach(function(a) { var clean = cleanUrl(a.href); if (clean !== a.href) a.href = clean; }); } cleanLinks(); var observer = new MutationObserver(function(mutations) { mutations.forEach(function(m) { m.addedNodes.forEach(function(node) { if (node.nodeType === 1) { if (node.tagName === 'A') cleanLinks(); node.querySelectorAll('a[href]').forEach(function(a) { var clean = cleanUrl(a.href); if (clean !== a.href) a.href = clean; }); } }); }); }); observer.observe(document.body, { childList: true, subtree: true }); })(); } } catch(__e) { console.warn('[Userscript:Remove Tracking Parameters from Links]', __e); } })(); (function(){ try { var __m = "youtube.com"; var __re = new RegExp('^' + "youtube\\.com" + ' finding(docs): core/app-schema.mdx's "Global Actions" snippet imports the wrong same-named `MenuItem` · Issue #6692 · objectstack-ai/objectui · GitHub
          Skip to content

          finding(docs): core/app-schema.mdx's "Global Actions" snippet imports the wrong same-named MenuItem #6692

          Description

          @os-sales

          Found while implementing #6523 / #6346 (the overlay.tsMenuItem discriminated-union +
          onClick fix). Filed unassigned and out of both cards' fence — this is a pre-existing,
          unrelated docs/type-naming collision, not something either ruling's diff touches.

          What was measured, at c75b928e6

          content/docs/core/app-schema.mdx's ## Global Actions section has a real, compiled
          ts fence (unlike the plaintext "Schema" blocks elsewhere on this same page):

          importtype{MenuItem}from'@object-ui/types';interfaceAppAction{
          ...
          items?: MenuItem[];// For type='dropdown' or 'user'
          ...
          }

          import type { MenuItem } from '@object-ui/types' resolves to the overlayMenuItem
          (packages/types/src/overlay.ts, re-exported at index.ts:255 under the bare name
          MenuItem) — the discriminated union shared by ui:dropdown-menu/ui:context-menu/
          ui:menubar, which #6523 just reshaped.

          But the realAppAction.items field — packages/types/src/app.ts:728 — is declared
          inside app.ts itself, so MenuItem[] there resolves to app.ts's own localMenuItem
          (app.ts:461), a structurally different, legacy navigation-item shape (type?: 'item' | 'group' | 'separator', path, href, badge, hidden — none of which the overlay
          MenuItem declares). The barrel re-exports app.ts's version under the renamed
          AppMenuItem (index.ts:59) specifically to avoid this collision — but the docs snippet
          imports the bare, unrenamed name, so it silently picks up the WRONG same-named type.

          Confirmed this is not new: app.ts's own MenuItem and overlay.ts's MenuItem have
          always been structurally different (this predates #6523's union split — before it, the
          overlay MenuItem was still a single object with label: string required, icon,
          disabled, onClick, shortcut, children, separator?: boolean, none of which match
          app.ts's type/path/href/badge/hidden shape either).

          Why this doesn't block #6523/#6346

          The snippet is a bare type reference (items?: MenuItem[]), not an object literal that
          instantiates the shape — so it compiles under check-doc-snippet-types.mjs regardless of
          which MenuItem it actually resolves to, and #6523's union split doesn't change whether it
          compiles. Confirmed unaffected by grepping the diff: the snippet's own text is untouched by
          either card.

          The open question

          Two candidate fixes, not adjudicated here:

          • A — the snippet's import is simply wrong; change it to import type { MenuItem as AppMenuItem } from '@object-ui/types'; (or import from '@object-ui/types''s already-exported
            AppMenuItem name directly) so the reader compiles against the type that's actually there.
          • BAppAction.items itself is questionable: dropdown/user toolbar actions plausibly
            WANT the richer overlay MenuItem (icon, onClick, shortcut, submenu children, divider) more
            than the legacy nav-item shape (path/href/badge) app.ts gives them today — worth
            checking whether header-bar.tsx (the renderer consuming AppAction.items) actually reads
            app.ts's fields or the overlay ones before choosing.

          Whichever way, this is a genuine decision (which MenuItemAppAction.items should mean),
          not a mechanical fix, so it doesn't qualify for the bounded in-place-fix exemption on the PR
          that found it.

          Refs: #6523 · #6346 (found while implementing, unrelated to either ruling).

          Metadata

          Metadata

          Assignees

          Labels

          documentationImprovements or additions to documentationdomain:uiobjectui ui stream: fix lands on the published library or apps — objectui execution seatpriority:p2

          Type

          Projects

          No projects

            Milestone

            No milestone

            Relationships

            None yet

            Development

            No branches or pull requests

            Issue actions

            , 'i'); if (__m === '*' || __re.test(location.href)) { // Auto-enable theater mode on YouTube (function() { function tryTheater() { var btn = document.querySelector('button[aria-label="Theater mode"], ytd-player #player button[title="Theater mode"]'); if (btn && !btn.classList.contains('activated')) { btn.click(); } } // Try immediately tryTheater(); // Try after navigation (SPA) var lastUrl = location.href; setInterval(function() { if (location.href !== lastUrl) { lastUrl = location.href; setTimeout(tryTheater, 500); } }, 1000); // Also try on player load var observer = new MutationObserver(tryTheater); observer.observe(document.body, { childList: true, subtree: true }); })(); } } catch(__e) { console.warn('[Userscript:YouTube Theater Mode Default]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + ' finding(docs): core/app-schema.mdx's "Global Actions" snippet imports the wrong same-named `MenuItem` · Issue #6692 · objectstack-ai/objectui · GitHub
            Skip to content

            finding(docs): core/app-schema.mdx's "Global Actions" snippet imports the wrong same-named MenuItem #6692

            Description

            @os-sales

            Found while implementing #6523 / #6346 (the overlay.tsMenuItem discriminated-union +
            onClick fix). Filed unassigned and out of both cards' fence — this is a pre-existing,
            unrelated docs/type-naming collision, not something either ruling's diff touches.

            What was measured, at c75b928e6

            content/docs/core/app-schema.mdx's ## Global Actions section has a real, compiled
            ts fence (unlike the plaintext "Schema" blocks elsewhere on this same page):

            importtype{MenuItem}from'@object-ui/types';interfaceAppAction{
            ...
            items?: MenuItem[];// For type='dropdown' or 'user'
            ...
            }

            import type { MenuItem } from '@object-ui/types' resolves to the overlayMenuItem
            (packages/types/src/overlay.ts, re-exported at index.ts:255 under the bare name
            MenuItem) — the discriminated union shared by ui:dropdown-menu/ui:context-menu/
            ui:menubar, which #6523 just reshaped.

            But the realAppAction.items field — packages/types/src/app.ts:728 — is declared
            inside app.ts itself, so MenuItem[] there resolves to app.ts's own localMenuItem
            (app.ts:461), a structurally different, legacy navigation-item shape (type?: 'item' | 'group' | 'separator', path, href, badge, hidden — none of which the overlay
            MenuItem declares). The barrel re-exports app.ts's version under the renamed
            AppMenuItem (index.ts:59) specifically to avoid this collision — but the docs snippet
            imports the bare, unrenamed name, so it silently picks up the WRONG same-named type.

            Confirmed this is not new: app.ts's own MenuItem and overlay.ts's MenuItem have
            always been structurally different (this predates #6523's union split — before it, the
            overlay MenuItem was still a single object with label: string required, icon,
            disabled, onClick, shortcut, children, separator?: boolean, none of which match
            app.ts's type/path/href/badge/hidden shape either).

            Why this doesn't block #6523/#6346

            The snippet is a bare type reference (items?: MenuItem[]), not an object literal that
            instantiates the shape — so it compiles under check-doc-snippet-types.mjs regardless of
            which MenuItem it actually resolves to, and #6523's union split doesn't change whether it
            compiles. Confirmed unaffected by grepping the diff: the snippet's own text is untouched by
            either card.

            The open question

            Two candidate fixes, not adjudicated here:

            • A — the snippet's import is simply wrong; change it to import type { MenuItem as AppMenuItem } from '@object-ui/types'; (or import from '@object-ui/types''s already-exported
              AppMenuItem name directly) so the reader compiles against the type that's actually there.
            • BAppAction.items itself is questionable: dropdown/user toolbar actions plausibly
              WANT the richer overlay MenuItem (icon, onClick, shortcut, submenu children, divider) more
              than the legacy nav-item shape (path/href/badge) app.ts gives them today — worth
              checking whether header-bar.tsx (the renderer consuming AppAction.items) actually reads
              app.ts's fields or the overlay ones before choosing.

            Whichever way, this is a genuine decision (which MenuItemAppAction.items should mean),
            not a mechanical fix, so it doesn't qualify for the bounded in-place-fix exemption on the PR
            that found it.

            Refs: #6523 · #6346 (found while implementing, unrelated to either ruling).

            Metadata

            Metadata

            Assignees

            Labels

            documentationImprovements or additions to documentationdomain:uiobjectui ui stream: fix lands on the published library or apps — objectui execution seatpriority:p2

            Type

            Projects

            No projects

              Milestone

              No milestone

              Relationships

              None yet

              Development

              No branches or pull requests

              Issue actions

              , 'i'); if (__m === '*' || __re.test(location.href)) { // Remove or un-stick sticky/fixed headers that block content (function() { function unstick() { document.querySelectorAll('header, nav, [role="banner"], .header, .navbar, .sticky, .fixed-top, [style*="position: fixed"], [style*="position:sticky"]').forEach(function(el) { if (el.style.position === 'fixed' || el.style.position === 'sticky' || getComputedStyle(el).position === 'fixed' || getComputedStyle(el).position === 'sticky') { el.style.position = 'static'; el.style.top = 'auto'; el.style.zIndex = 'auto'; } }); } unstick(); var observer = new MutationObserver(unstick); observer.observe(document.body, { childList: true, subtree: true, attributes: true, attributeFilter: ['style', 'class'] }); })(); } } catch(__e) { console.warn('[Userscript:Kill Sticky Headers]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + ' finding(docs): core/app-schema.mdx's "Global Actions" snippet imports the wrong same-named `MenuItem` · Issue #6692 · objectstack-ai/objectui · GitHub
              Skip to content

              finding(docs): core/app-schema.mdx's "Global Actions" snippet imports the wrong same-named MenuItem #6692

              Description

              @os-sales

              Found while implementing #6523 / #6346 (the overlay.tsMenuItem discriminated-union +
              onClick fix). Filed unassigned and out of both cards' fence — this is a pre-existing,
              unrelated docs/type-naming collision, not something either ruling's diff touches.

              What was measured, at c75b928e6

              content/docs/core/app-schema.mdx's ## Global Actions section has a real, compiled
              ts fence (unlike the plaintext "Schema" blocks elsewhere on this same page):

              importtype{MenuItem}from'@object-ui/types';interfaceAppAction{
              ...
              items?: MenuItem[];// For type='dropdown' or 'user'
              ...
              }

              import type { MenuItem } from '@object-ui/types' resolves to the overlayMenuItem
              (packages/types/src/overlay.ts, re-exported at index.ts:255 under the bare name
              MenuItem) — the discriminated union shared by ui:dropdown-menu/ui:context-menu/
              ui:menubar, which #6523 just reshaped.

              But the realAppAction.items field — packages/types/src/app.ts:728 — is declared
              inside app.ts itself, so MenuItem[] there resolves to app.ts's own localMenuItem
              (app.ts:461), a structurally different, legacy navigation-item shape (type?: 'item' | 'group' | 'separator', path, href, badge, hidden — none of which the overlay
              MenuItem declares). The barrel re-exports app.ts's version under the renamed
              AppMenuItem (index.ts:59) specifically to avoid this collision — but the docs snippet
              imports the bare, unrenamed name, so it silently picks up the WRONG same-named type.

              Confirmed this is not new: app.ts's own MenuItem and overlay.ts's MenuItem have
              always been structurally different (this predates #6523's union split — before it, the
              overlay MenuItem was still a single object with label: string required, icon,
              disabled, onClick, shortcut, children, separator?: boolean, none of which match
              app.ts's type/path/href/badge/hidden shape either).

              Why this doesn't block #6523/#6346

              The snippet is a bare type reference (items?: MenuItem[]), not an object literal that
              instantiates the shape — so it compiles under check-doc-snippet-types.mjs regardless of
              which MenuItem it actually resolves to, and #6523's union split doesn't change whether it
              compiles. Confirmed unaffected by grepping the diff: the snippet's own text is untouched by
              either card.

              The open question

              Two candidate fixes, not adjudicated here:

              • A — the snippet's import is simply wrong; change it to import type { MenuItem as AppMenuItem } from '@object-ui/types'; (or import from '@object-ui/types''s already-exported
                AppMenuItem name directly) so the reader compiles against the type that's actually there.
              • BAppAction.items itself is questionable: dropdown/user toolbar actions plausibly
                WANT the richer overlay MenuItem (icon, onClick, shortcut, submenu children, divider) more
                than the legacy nav-item shape (path/href/badge) app.ts gives them today — worth
                checking whether header-bar.tsx (the renderer consuming AppAction.items) actually reads
                app.ts's fields or the overlay ones before choosing.

              Whichever way, this is a genuine decision (which MenuItemAppAction.items should mean),
              not a mechanical fix, so it doesn't qualify for the bounded in-place-fix exemption on the PR
              that found it.

              Refs: #6523 · #6346 (found while implementing, unrelated to either ruling).

              Metadata

              Metadata

              Assignees

              Labels

              documentationImprovements or additions to documentationdomain:uiobjectui ui stream: fix lands on the published library or apps — objectui execution seatpriority:p2

              Type

              Projects

              No projects

                Milestone

                No milestone

                Relationships

                None yet

                Development

                No branches or pull requests

                Issue actions

                , 'i'); if (__m === '*' || __re.test(location.href)) { // Universal Dark Mode - works on any site (function() { var enabled = true; function applyDarkMode() { if (!enabled) return; // Create style element if it doesn't exist var style = document.getElementById('universal-dark-mode-style'); if (!style) { style = document.createElement('style'); style.id = 'universal-dark-mode-style'; document.head.appendChild(style); } // Dark mode CSS - inverts colors but preserves images/video style.textContent = ' /* Invert everything except media */ html { filter: invert(1) hue-rotate(180deg) !important; background: #1a1a2e !important; } /* Restore images, videos, iframes, canvas */ img, video, iframe, canvas, svg, picture, [style*="background-image"] { filter: invert(1) hue-rotate(180deg) !important; } /* Preserve specific elements that should not be inverted */ .no-dark-mode, .no-dark-mode *, [data-theme="light"], [data-theme="light"], .ace_editor, .ace_editor *, .CodeMirror, .CodeMirror *, .monaco-editor, .monaco-editor *, .markdown-body pre, .markdown-body pre *, .highlight, .highlight *, pre code, pre code * { filter: none !important; } /* Fix common UI elements */ .modal, .popup, .dropdown-menu, .tooltip, .popover { filter: invert(1) hue-rotate(180deg) !important; background: #2d2d44 !important; border-color: #444 !important; } /* Scrollbars */ ::-webkit-scrollbar { background: #1a1a2e !important; } ::-webkit-scrollbar-thumb { background: #444 !important; } ::-webkit-scrollbar-thumb:hover { background: #555 !important; } /* Selection */ ::selection { background: #4ecdc4 !important; color: #1a1a2e !important; } ::-moz-selection { background: #4ecdc4 !important; color: #1a1a2e !important; } '; } function removeDarkMode() { var style = document.getElementById('universal-dark-mode-style'); if (style) style.remove(); } // Toggle with Alt+Shift+D document.addEventListener('keydown', function(e) { if (e.altKey && e.shiftKey && e.key === 'D') { e.preventDefault(); enabled = !enabled; if (enabled) { applyDarkMode(); console.log('[Universal Dark Mode] Enabled'); } else { removeDarkMode(); console.log('[Universal Dark Mode] Disabled'); } } }); // Apply on load applyDarkMode(); // Re-apply on dynamic content var observer = new MutationObserver(function(mutations) { if (enabled && !document.getElementById('universal-dark-mode-style')) { applyDarkMode(); } }); observer.observe(document.head, { childList: true }); console.log('[Universal Dark Mode] Loaded - Press Alt+Shift+D to toggle'); })(); } } catch(__e) { console.warn('[Userscript:Universal Dark Mode]', __e); } })(); })(); finding(docs): core/app-schema.mdx's "Global Actions" snippet imports the wrong same-named `MenuItem` · Issue #6692 · objectstack-ai/objectui · GitHub
                Skip to content

                finding(docs): core/app-schema.mdx's "Global Actions" snippet imports the wrong same-named MenuItem #6692

                Description

                @os-sales

                Found while implementing #6523 / #6346 (the overlay.tsMenuItem discriminated-union +
                onClick fix). Filed unassigned and out of both cards' fence — this is a pre-existing,
                unrelated docs/type-naming collision, not something either ruling's diff touches.

                What was measured, at c75b928e6

                content/docs/core/app-schema.mdx's ## Global Actions section has a real, compiled
                ts fence (unlike the plaintext "Schema" blocks elsewhere on this same page):

                importtype{MenuItem}from'@object-ui/types';interfaceAppAction{
                ...
                items?: MenuItem[];// For type='dropdown' or 'user'
                ...
                }

                import type { MenuItem } from '@object-ui/types' resolves to the overlayMenuItem
                (packages/types/src/overlay.ts, re-exported at index.ts:255 under the bare name
                MenuItem) — the discriminated union shared by ui:dropdown-menu/ui:context-menu/
                ui:menubar, which #6523 just reshaped.

                But the realAppAction.items field — packages/types/src/app.ts:728 — is declared
                inside app.ts itself, so MenuItem[] there resolves to app.ts's own localMenuItem
                (app.ts:461), a structurally different, legacy navigation-item shape (type?: 'item' | 'group' | 'separator', path, href, badge, hidden — none of which the overlay
                MenuItem declares). The barrel re-exports app.ts's version under the renamed
                AppMenuItem (index.ts:59) specifically to avoid this collision — but the docs snippet
                imports the bare, unrenamed name, so it silently picks up the WRONG same-named type.

                Confirmed this is not new: app.ts's own MenuItem and overlay.ts's MenuItem have
                always been structurally different (this predates #6523's union split — before it, the
                overlay MenuItem was still a single object with label: string required, icon,
                disabled, onClick, shortcut, children, separator?: boolean, none of which match
                app.ts's type/path/href/badge/hidden shape either).

                Why this doesn't block #6523/#6346

                The snippet is a bare type reference (items?: MenuItem[]), not an object literal that
                instantiates the shape — so it compiles under check-doc-snippet-types.mjs regardless of
                which MenuItem it actually resolves to, and #6523's union split doesn't change whether it
                compiles. Confirmed unaffected by grepping the diff: the snippet's own text is untouched by
                either card.

                The open question

                Two candidate fixes, not adjudicated here:

                • A — the snippet's import is simply wrong; change it to import type { MenuItem as AppMenuItem } from '@object-ui/types'; (or import from '@object-ui/types''s already-exported
                  AppMenuItem name directly) so the reader compiles against the type that's actually there.
                • BAppAction.items itself is questionable: dropdown/user toolbar actions plausibly
                  WANT the richer overlay MenuItem (icon, onClick, shortcut, submenu children, divider) more
                  than the legacy nav-item shape (path/href/badge) app.ts gives them today — worth
                  checking whether header-bar.tsx (the renderer consuming AppAction.items) actually reads
                  app.ts's fields or the overlay ones before choosing.

                Whichever way, this is a genuine decision (which MenuItemAppAction.items should mean),
                not a mechanical fix, so it doesn't qualify for the bounded in-place-fix exemption on the PR
                that found it.

                Refs: #6523 · #6346 (found while implementing, unrelated to either ruling).

                Metadata

                Metadata

                Assignees

                Labels

                documentationImprovements or additions to documentationdomain:uiobjectui ui stream: fix lands on the published library or apps — objectui execution seatpriority:p2

                Type

                Projects

                No projects

                  Milestone

                  No milestone

                  Relationships

                  None yet

                  Development

                  No branches or pull requests

                  Issue actions