SolidStart routes, edited in the browser with nothing installed

Because it decides whether there is a seam to instrument. SolidStart 1 runs its dev server through vinxi, which takes no flag pointing at a config, so a plugin cannot be handed to it from outside. SolidStart 2 dropped vinxi: the scaffold ships a direct vite dependency, a real root vite.config.ts, and a dev script that is literally vite dev. That is an ordinary Vite project as far as instrumentation is concerned, so it needs nothing added.

No. PortBay launches your dev server, so it passes a generated config that imports and spreads your own vite.config and adds a source-location plugin carried inside the app. The generated file lives in PortBay's data directory and never in your repo, so package.json, node_modules and vite.config.ts stay byte-identical whether PortBay is installed or not.

The stamps were measured on served HTML rather than inferred from the config, because a generated config being right and a framework actually reading it have turned out to be different things more than once. Two runs of the same SolidStart 2 project, differing only in the flag: 3016 bytes and zero coordinates without it, 3219 bytes and five with it, naming real lines in src/routes/index.tsx and src/components/Counter.tsx.

Text, class and attribute edits, and page settings — all four write lanes. What is lost is the precision tier: without a coordinate, edits are resolved by finding your markup in the route files instead, structural edits are refused rather than guessed, and style edits go to a PortBay override sheet rather than into your source. PortBay says which mode it is in rather than degrading quietly.

Into the route's own @solidjs/meta components — the <Title> and <Meta> tags in that file's JSX. They portal into the real document head at runtime from wherever they sit in the tree, so PortBay reads and writes them in place rather than trying to find a static HTML head that does not exist. A field the route has no tag for is inserted into the same tree.

Component usages, the same as every other .tsx file. Host elements you wrote carry coordinates; a <Counter /> tag does not, so markup produced by a component you did not author has no coordinate to follow. The reason is that a capitalised tag in a .tsx can be a TypeScript generic parameter list rather than a component, and guessing wrong would insert a syntax error into your module.

No. It is a Pro feature, still in early access behind an opt-in toggle in Settings, and it is not compiled into the open-source build. It refuses to run while the project is shared over a public tunnel, and the edit bar works only on local .test hosts. Running SolidStart on a real .test domain with trusted HTTPS is in the free app.

Yes, on the precise lane. JSX and TSX are among the four formats where that structural edit is supported, so an element in a route file can be moved into a new component file, with the import added and the original span replaced by the tag, all in one save. A span carrying a template expression is refused by name instead: the expression's route-local values would not exist in the new file, and the splice would produce source that does not compile.