This project is using Qwik with QwikCity. QwikCity is just an extra set of tools on top of Qwik to make it easier to build a full site, including directory-based routing, layouts, and more.
Inside your project, you'll see the following directory structure:
├── public/
│ └── ...
└── src/
├── components/
│ └── ...
└── routes/
└── ...
-
src/routes
: Provides the directory-based routing, which can include a hierarchy oflayout.tsx
layout files, and anindex.tsx
file as the page. Additionally,index.ts
files are endpoints. Please see the routing docs for more info. -
src/components
: Recommended directory for components. -
public
: Any static assets, like images, can be placed in the public directory. Please see the Vite public directory for more info.
Use the pnpm qwik add
command to add additional integrations. Some examples of integrations includes: Cloudflare, Netlify or Express Server, and the Static Site Generator (SSG).
pnpm qwik add # or `yarn qwik add`
Development mode uses Vite's development server. The dev
command will server-side render (SSR) the output during development.
npm start # or `yarn start`
Note: during dev mode, Vite may request a significant number of
.js
files. This does not represent a Qwik production build.
The preview command will create a production build of the client modules, a production build of src/entry.preview.tsx
, and run a local server. The preview server is only for convenience to preview a production build locally and should not be used as a production server.
pnpm preview # or `yarn preview`
The production build will generate client and server modules by running both client and server build commands. The build command will use Typescript to run a type check on the source code.
pnpm build # or `yarn build`
This starter site is configured to deploy to Vercel Edge Functions, which means it will be rendered at an edge location near to your users.
The adaptor will add a new vite.config.ts
within the adapters/
directory, and a new entry file will be created, such as:
└── adapters/
└── vercel-edge/
└── vite.config.ts
└── src/
└── entry.vercel-edge.tsx
Additionally, within the package.json
, the build.server
script will be updated with the Vercel Edge build.
To build the application for production, use the build
command, this command will automatically run pnpm build.server
and pnpm build.client
:
pnpm build
To deploy the application for development:
pnpm deploy
Notice that you might need a Vercel account in order to complete this step!
The project is ready to be deployed to Vercel. However, you will need to create a git repository and push the code to it.
You can deploy your site to Vercel either via a Git provider integration or through the Vercel CLI.
This starter site is configured to deploy to Vercel Edge Functions, which means it will be rendered at an edge location near to your users.
The adaptor will add a new vite.config.ts
within the adapters/
directory, and a new entry file will be created, such as:
└── adapters/
└── vercel-edge/
└── vite.config.ts
└── src/
└── entry.vercel-edge.tsx
Additionally, within the package.json
, the build.server
script will be updated with the Vercel Edge build.
To build the application for production, use the build
command, this command will automatically run pnpm build.server
and pnpm build.client
:
pnpm build
To deploy the application for development:
pnpm deploy
Notice that you might need a Vercel account in order to complete this step!
The project is ready to be deployed to Vercel. However, you will need to create a git repository and push the code to it.
You can deploy your site to Vercel either via a Git provider integration or through the Vercel CLI.
This starter site is configured to deploy to Vercel Edge Functions, which means it will be rendered at an edge location near to your users.
The adaptor will add a new vite.config.ts
within the adapters/
directory, and a new entry file will be created, such as:
└── adapters/
└── vercel-edge/
└── vite.config.ts
└── src/
└── entry.vercel-edge.tsx
Additionally, within the package.json
, the build.server
script will be updated with the Vercel Edge build.
To build the application for production, use the build
command, this command will automatically run pnpm build.server
and pnpm build.client
:
pnpm build
To deploy the application for development:
pnpm deploy
Notice that you might need a Vercel account in order to complete this step!
The project is ready to be deployed to Vercel. However, you will need to create a git repository and push the code to it.
You can deploy your site to Vercel either via a Git provider integration or through the Vercel CLI.
This starter site is configured to deploy to Netlify Edge Functions, which means it will be rendered at an edge location near to your users.
The Netlify CLI can be used to preview a production build locally. To do so: First build your site, then to start a local server, run:
- Install Netlify CLI globally
npm i -g netlify-cli
. - Build your site with both ssr and static
pnpm build
. - Start a local server with
pnpm serve
. In this project,pnpm serve
uses thenetlify dev
command to spin up a server that can handle Netlify's Edge Functions locally. - Visit http://localhost:8888/ to check out your site.
Netlify Edge Functions declarations can be configured to run on specific URL patterns. Each edge function declaration associates one site path pattern with one function to execute on requests that match the path. A single request can execute a chain of edge functions from a series of declarations. A single edge function can be associated with multiple paths across various declarations.
This is useful to determine if a page response should be Server-Side Rendered (SSR) or
if the response should use a static-site generated (SSG) index.html
file instead.
By default, the Netlify Edge adaptor will generate a .netlify/edge-middleware/manifest.json
file, which is used by the Netlify deployment to determine which paths should, and should not, use edge functions.
To override the generated manifest, you can add a declaration to the netlify.toml
using the [[edge_functions]]
config. For example:
[[edge_functions]]
path = "/admin"
function = "auth"
Netlify-specific option fields that can be passed to the adapter options:
excludedPath
this option accepts astring
glob pattern that represents which path pattern should not go through the generated Edge Functions.
You can deploy your site to Netlify either via a Git provider integration or through the Netlify CLI. This starter site includes a netlify.toml
file to configure your build for deployment.
Once your site has been pushed to your Git provider, you can either link it in the Netlify UI or use the CLI. To link your site to a Git provider from the Netlify CLI, run the command:
netlify link
This sets up continuous deployment for your site's repo. Whenever you push new commits to your repo, Netlify starts the build process..
If you wish to deploy from the CLI rather than using Git, you can use the command:
netlify deploy --build
You must use the --build
flag whenever you deploy. This ensures that the Edge Functions that this starter site relies on are generated and available when you deploy your site.
Add --prod
flag to deploy to production.
Cloudflare's wrangler CLI can be used to preview a production build locally. To start a local server, run:
pnpm serve
Then visit http://localhost:8787/
Cloudflare Pages are deployable through their Git provider integrations.
If you don't already have an account, then create a Cloudflare account here. Next go to your dashboard and follow the Cloudflare Pages deployment guide.
Within the projects "Settings" for "Build and deployments", the "Build command" should be pnpm build
, and the "Build output directory" should be set to dist
.
Cloudflare Page's function-invocation-routes config can be used to include, or exclude, certain paths to be used by the worker functions. Having a _routes.json
file gives developers more granular control over when your Function is invoked.
This is useful to determine if a page response should be Server-Side Rendered (SSR) or if the response should use a static-site generated (SSG) index.html
file.
By default, the Cloudflare pages adaptor does not include a public/_routes.json
config, but rather it is auto-generated from the build by the Cloudflare adaptor. An example of an auto-generate dist/_routes.json
would be:
{
"include": [
"/*"
],
"exclude": [
"/_headers",
"/_redirects",
"/build/*",
"/favicon.ico",
"/manifest.json",
"/service-worker.js",
"/about"
],
"version": 1
}
In the above example, it's saying all pages should be SSR'd. However, the root static files such as /favicon.ico
and any static assets in /build/*
should be excluded from the Functions, and instead treated as a static file.
In most cases the generated dist/_routes.json
file is ideal. However, if you need more granular control over each path, you can instead provide you're own public/_routes.json
file. When the project provides its own public/_routes.json
file, then the Cloudflare adaptor will not auto-generate the routes config and instead use the committed one within the public
directory.
This starter site is configured to deploy to Vercel Edge Functions, which means it will be rendered at an edge location near to your users.
The adaptor will add a new vite.config.ts
within the adapters/
directory, and a new entry file will be created, such as:
└── adapters/
└── vercel-edge/
└── vite.config.ts
└── src/
└── entry.vercel-edge.tsx
Additionally, within the package.json
, the build.server
script will be updated with the Vercel Edge build.
To build the application for production, use the build
command, this command will automatically run pnpm build.server
and pnpm build.client
:
pnpm build
To deploy the application for development:
pnpm deploy
Notice that you might need a Vercel account in order to complete this step!
The project is ready to be deployed to Vercel. However, you will need to create a git repository and push the code to it.
You can deploy your site to Vercel either via a Git provider integration or through the Vercel CLI.