sandbox/vite
A Vite Sandbox for Multi-File, Glob-Driven Projects
Build a real multi-file project the Vite way — pages and data discovered with import.meta.glob, configuration in .env — in a browser workspace with a terminal and Git.
// routes come from the pages/ folder, not a list
const pages = import.meta.glob('./pages/*.ts');
export const routes = Object.entries(pages).map(
([path, load]) => ({
url: toRoute(path), // ./pages/about.ts → /about
load, // lazy: imported on navigate
})
);01 platform
When a Vite project outgrows a single file
A glob import and an env variable are quick to show in one file. A real project is what happens when there are twenty files, a folder of routes and a second person reading it — and that is what this workspace is for.
-
A folder tree, not a scratch file
Split a project across
pages/,lib/anddata/the way you actually would. The file tree, tabs and per-project history are the ones a real project needs, not a single editable pane. -
The folder is the route table
Because pages are discovered by glob, structure carries meaning: a file in
pages/is a route, and the project stays organized because the filesystem is the source of truth. -
Config that lives with the project
A
.envat the root travels with the workspace, so the same project resolves the same values on any machine you open it on — no separate setup to remember. -
Version control, in the tab
Commit as the project grows and read its history through isomorphic-git, offline, then export the whole tree as a zip when you want it on disk.
02 deep dive
Pages and data, discovered by glob
At project scale, glob imports stop being a trick and become the architecture — the thing that keeps a growing app from needing a hand-maintained index.
Routes come from a folder. import.meta.glob('./pages/*.ts') turns the pages/ directory into the route table, so adding a screen is adding a file. Nothing else has to know it exists.
Content comes from a folder. The same pattern over data/ or posts/ gives you a collection you can list, sort and render, which is why a file-based blog or docs site fits this shape so well.
Lazy loaders keep it fast as it grows. Left lazy, each glob entry is a dynamic import, so a twenty-page project still only loads the page a visitor asked for — the split points come for free from the structure.
- routes
- glob ./pages
- content
- glob ./data
- growth
- add a file
- loading
- lazy per page
src/
pages/ ← each file is a route (globbed)
data/ ← posts and content (globbed)
lib/ ← shared helpers
router.ts ← builds routes from pages/
.env ← VITE_ config for this project03 pipeline
How a Vite Lite project grows here
The path from a one-file idea to a structured project, with the workspace absorbing each step instead of you configuring it.
-
Start from the starter
Open the Vite Lite workspace and you have a working file-based project — a folder of content, a glob that lists it, and a
.env— rather than an empty editor. -
Add folders
Create
pages/,lib/anddata/and move code into them. The glob patterns pick up new files automatically, so structure does not cost you a config edit. -
Install what you need
Pull a router, a markdown parser or a framework from the npm panel; each resolves through esm.sh into the import map and imports across the whole project.
-
Commit and hand over
Stage and commit with Git as you go, then export the zip or share a live link. The project opens the same way for the next person, config included.
04 features
What the workspace adds to a Vite project
Everything below is on the moment you open the Vite workspace — the parts a single-file playground leaves out because a real project is the point here.
-
A real file tree
Folders, tabs, drag-to-move and per-project file history with restore points — the project management a multi-file Vite app actually needs, not a single pane.
-
Autocomplete across files
Monaco reads your own modules, so importing from
lib/or a glob map autocompletes with the symbols you defined, across the whole tree. -
An integrated terminal
A shell surface over the project files for the moments a GUI is slower than typing — moving files, inspecting the tree, scripting a change.
-
TypeScript across the project
.tsand.tsxthroughout, stripped by esbuild with notsconfigto maintain, so types help across modules without slowing the build. -
npm for the whole tree
Install once and every file resolves the package through the shared import map — a router or a parser is available project-wide, with no node_modules.
-
Git and zip export
Commit history in the browser through isomorphic-git, and a zip export that opens locally with its structure and
.envintact — no lock-in.
05 deep dive
One .env per project, read at build
In a real project the interesting thing about env is not the syntax — it is that the configuration belongs to the project and moves with it.
The file is part of the workspace. A .env at the root is committed and exported with everything else, so cloning or handing over the project carries its configuration rather than leaving the next person to reconstruct it.
The VITE_ rule keeps client code honest. Only prefixed keys are inlined into the build, so a value you did not mean to expose stays out of the bundle — the same guardrail across a large project as a small one.
Values are inlined at build. import.meta.env.VITE_API_BASE becomes a constant when the project compiles, so there is no runtime config object to thread through modules that are spread across folders.
- scope
- one .env per project
- travels
- committed + exported
- exposed
- VITE_ keys only
- inlined
- at build time
// resolved at build from .env, usable anywhere
const base = import.meta.env.VITE_API_BASE;
export function get(path: string) {
return fetch(`${base}${path}`).then((r) => r.json());
}06 workflow
From a folder of routes to a committed project
The workspace loop, from a structured start to something committed and shareable — no dev server to keep alive along the way.
- new project → Vite Lite (workspace)
- created src/pages, src/lib, .env, router.ts
- add src/pages/about.ts
- glob rematched · /about live · router untouched
- install marked
- resolved via esm.sh · import map updated
- git commit -m "about page + markdown"
- [main b90ee14] about page + markdown · 5 files
- export project.zip
- tree + .env bundled · opens the same locally
-
Structure does the routing
Adding a page is adding a file; the glob picks it up and the router does not change, so growth stays cheap.
-
The project is portable
Export the zip and it opens elsewhere with its folders and
.envintact — the workspace is not a place your project is trapped. -
Honest about the edges
This is the Vite authoring model at project scale, not the Node dev server — a build for production still runs on a machine.
07 ecosystem
A Vite workspace for any front end
A Vite-style workspace is not tied to one framework — import React, Vue, Svelte or Solid into it and the editor compiles each per file beside your glob-built routes.
08 languages
What the workspace compiles around Vite
A Vite-style project sits beside every other language the editor compiles in the browser, renders natively, or runs on demand.
Compiled in your browser11
Zero build step. Transform runs on a Web Worker, so typing never blocks.
- JSX
- TSX
- TypeScript
- Vue SFC
- Svelte
- Angular (JIT)
- SolidJS
- SCSS
- Sass
- Less
- Pug
Rendered natively8
Straight to the live preview, no transform in the way.
- HTML
- CSS
- JavaScript
- JSON
- Markdown
- Jupyter (.ipynb)
- SVG
- YAML
Executed on demand22
70+ languages run through a self-hosted Piston engine. stdout, stderr, images and tracebacks land in the console.
- Python
- Java
- C
- C++
- C#
- Go
- Rust
- Ruby
- PHP
- Kotlin
- Swift
- Lua
- Scala
- Perl
- Haskell
- Elixir
- Dart
- R
- Julia
- SQLite
- Bash
- PowerShell
09 questions
The Vite sandbox — common questions
How is the sandbox different from the Vite Lite starter page?
The sandbox is the multi-file project workflow: a folder tree, glob-built routes across directories, a terminal, Git and export. The starter page focuses on the individual Vite features. Both use the same browser-based Vite Lite pipeline, with no Node dev server.
Can I organize a project into folders here?
Yes. Create pages/, lib/ and data/ and split the code the way you would locally. Because routes and content are discovered by import.meta.glob, adding a file to a folder is enough — there is no index or manifest to update by hand.
Does import.meta.glob work across a real folder structure?
Yes. A pattern like import.meta.glob('./pages/*.ts') turns a directory into a set of modules or lazy loaders, which is how the workspace builds routes and content collections from the filesystem rather than a hand-written list.
Can I use TypeScript across the whole project?
Yes. Write .ts and .tsx anywhere in the tree; esbuild strips the types on a fast pass with no tsconfig to maintain, and Monaco autocompletes across your own modules as the project grows.
How do environment variables work in a project?
A single .env at the project root holds VITE_-prefixed keys, import.meta.env inlines them at build, and the file is committed and exported with the project — so configuration travels with the code to any machine.
Can I use Git and export the project?
Yes. Stage, commit and branch through isomorphic-git in the browser, offline, and export the whole tree as a zip that opens locally with its structure and .env intact, so there is no lock-in.
Is this the full Vite CLI with plugins?
No. The workspace runs the browser-friendly Vite authoring features — glob imports, env, TypeScript, zero config — compiled with esbuild. Vite's plugin system and production build run in Node, so those belong on a local machine.
Does npm work project-wide?
Yes. Install a package once and every file in the project resolves it through the shared native import map, so a router or a markdown parser is available across the whole tree with no node_modules folder.
Do I need to install anything to use XCODX Studio?
No. XCODX Studio is a browser-based IDE — the editor, the compilers and the preview all run client-side. There is no download, no package manager to set up and no configuration file to write. Opening the editor is the whole setup step.
Where is my code stored?
In your own browser. Projects, file history and Git objects live in local storage on your device and are never uploaded to a server. That also means XCODX works offline: it is a Progressive Web App, so you can install it and keep coding with no connection.
Is XCODX Studio free?
Yes. The editor, the live preview, the 70+ language runtimes, npm installs, Git and the integrated terminal are all free to use.
Can I use XCODX on a tablet or Chromebook?
Yes. The editor is a responsive web app, so a Chromebook, an iPad or an Android tablet gets the same compilers and the same preview a laptop does — there is no desktop-only build, because there is no build to install at all. The layout adapts to the screen rather than shrinking a desktop UI into it.
Can I export a project or move it to my own machine?
Yes. Export the whole project as a zip with its folder structure intact and open it locally, or commit it and push. It is ordinary source on disk from that point on — no proprietary format and no lock-in, which is also why importing an existing repository from GitHub works the same way in reverse.
Nothing to install
Open a Vite workspace
A structured, glob-driven project on screen in under a minute — folder tree, Git and a terminal, with no account wall and nothing to install.