content/docs/utilities/vscode-extension.mdx — the published page for the
extension, and the homepage its manifest points at — describes the
ObjectUI: Export to React command in two ways the command does not behave. Found
while measuring what that command promises about the JSX transform for
objectui#7862; neither is in that card's file surface, so both are filed.
1. It says the output goes to the clipboard. It does not.
The page's Usage list reads:
- React component code is copied to clipboard
exportToReact() in packages/vscode-extension/src/extension.ts does no such thing.
It calls vscode.workspace.openTextDocument with the generated content and
language: 'typescriptreact', shows it, and then shows the message
React component generated! Save it to a .tsx file. Nothing in the package writes to
the clipboard: the identifier clipboard does not occur in src/ at all. A reader
following the documented steps pastes whatever was on their clipboard already.
2. Its Output Example omits the side-effect import objectui#7837 established
The page's Output Example imports only SchemaRenderer from @object-ui/react. The
command's actual preamble also carries:
// Importing the package registers every default renderer as a side effect —
// there is no separate registration call.
import '@object-ui/components';
That line is load-bearing. objectui#7837 measured it: @object-ui/components
declares sideEffects: true, its barrel runs import './renderers', and its built
dist/index.js carries 114 module-scope register( call sites. Without that import
no renderer is registered, so a user who copies the documented example rather than
running the command gets a SchemaRenderer with nothing to render.
Note on what is NOT wrong here
The example also shows no import React from 'react', which as of objectui#7862 is
correct and matches what the command now emits. That half of the page was already
right and should be left alone.
Why nothing catches either one
The command's output lives inside a template literal, so this package's
tsc --noEmit sees one string; the doc gates that read content/docs check fence
languages, snippet types and links, none of which can compare a documented example
against the generator that is supposed to produce it. Same mechanism as
objectui#7837 and objectui#7862, a third surface over.
Filed unassigned; a maintainer should decide whether the fix is to correct the prose
or to bind the page's fence to the template's product the way objectui#7862's pin
now binds the compile.
Generated by Claude Code
content/docs/utilities/vscode-extension.mdx— the published page for theextension, and the
homepageits manifest points at — describes theObjectUI: Export to Reactcommand in two ways the command does not behave. Foundwhile measuring what that command promises about the JSX transform for
objectui#7862; neither is in that card's file surface, so both are filed.
1. It says the output goes to the clipboard. It does not.
The page's Usage list reads:
exportToReact()inpackages/vscode-extension/src/extension.tsdoes no such thing.It calls
vscode.workspace.openTextDocumentwith the generated content andlanguage: 'typescriptreact', shows it, and then shows the messageReact component generated! Save it to a .tsx file.Nothing in the package writes tothe clipboard: the identifier
clipboarddoes not occur insrc/at all. A readerfollowing the documented steps pastes whatever was on their clipboard already.
2. Its Output Example omits the side-effect import objectui#7837 established
The page's Output Example imports only
SchemaRendererfrom@object-ui/react. Thecommand's actual preamble also carries:
That line is load-bearing. objectui#7837 measured it:
@object-ui/componentsdeclares
sideEffects: true, its barrel runsimport './renderers', and its builtdist/index.jscarries 114 module-scoperegister(call sites. Without that importno renderer is registered, so a user who copies the documented example rather than
running the command gets a SchemaRenderer with nothing to render.
Note on what is NOT wrong here
The example also shows no
import React from 'react', which as of objectui#7862 iscorrect and matches what the command now emits. That half of the page was already
right and should be left alone.
Why nothing catches either one
The command's output lives inside a template literal, so this package's
tsc --noEmitsees one string; the doc gates that readcontent/docscheck fencelanguages, snippet types and links, none of which can compare a documented example
against the generator that is supposed to produce it. Same mechanism as
objectui#7837 and objectui#7862, a third surface over.
Filed unassigned; a maintainer should decide whether the fix is to correct the prose
or to bind the page's fence to the template's product the way objectui#7862's pin
now binds the compile.
Generated by Claude Code