qwik Documentation

Instant-loading web apps, without effort

22,040 stars TypeScript TypeScript 1 file ยท ~2,036 tokens #framework#hacktoberfest#javascript#web
RAW Doc

Docker & Self-Hosted Deployment Verified OCI

Deploy qwik on any server, homelab, or cloud container platform.

1-Click Terminal Command
bash (docker run)
docker run -d --name qwik --restart always qwikdev/qwik:latest

File: README.md

Instant-loading web apps, without effort

This is the branch for Qwik v2, currently in beta. For v1, see the v1
branch.

Qwik offers the fastest possible page load times - regardless of the complexity of your website. Qwik is so fast because it allows fully interactive sites to load with almost no JavaScript and pick up from where the server left off.

As users interact with the site, only the necessary parts of the site load on-demand. This precision lazy-loading is what makes Qwik so quick.

Getting Started

sh
npm create qwik@beta
# or
pnpm create qwik@beta
# or
yarn create qwik@beta
# or
bun create qwik@beta

Nightlies

We use pkg.pr.new to make packages available for each PR and for the branches. Use these URLs instead of versions to get the latest build:

Resources

Community

Development

  • See Contributing.md for more information on how to build Qwik from the source and contribute!
  • Partytown: Relocate resource intensive third-party scripts off of the main thread and into a web worker ๐ŸŽ‰.
  • Mitosis: Write components once, run everywhere. Compiles to Vue, React, Solid, Angular, Svelte, and more.
  • Builder: Drag and drop page builder and CMS for React, Vue, Angular, and more.
special sponsor
sponsors

File: e2e/qwik-cli-e2e/README.md

CLI E2E tests for the Qwik Framework

This package provides isolated E2E tests by generating a new application with local packages and then running tests again that code by executing it and verifying expected behavior.

Description

Tests can be invoked by running pnpm run test.e2e.cli.

Note that running E2E tests requires the workspace projects to be prebuilt manually!

E2E project does the following internally:

  1. Vitest is configured to run a setup function once PRIOR TO ALL tests. During the setup @qwik.dev/core, @qwik.dev/router and eslint-plugin-qwik packages will be packed with pnpm pack Those will be used at a step 2 for every test. Tarballs are located in temp/tarballs folder within this repo. It is assumed that packages are built before E2E is executed.

  2. Simulates npm create qwik locally using direct command node packages/create-qwik/create-qwik.mjs playground {outputDir}

    • By default outputDir is an auto-generated one using tmp npm package. The application that is created here will be removed after the test is executed
    • It is possible to install into custom folder using environment variable TEMP_E2E_PATH. Here's how the command would look like in this case:
    • with absolute path TEMP_E2E_PATH=/Users/name/projects/tests pnpm run test.e2e.cli
    • with path relative to the qwik workspace TEMP_E2E_PATH=temp/e2e-folder pnpm run test.e2e.cli

    Note that provided folder should exist. If custom path is used, generated application will not be removed after the test completes, which is helpful for debugging.

  3. Uses packed @qwik.dev/core, @qwik.dev/router and eslint-plugin-qwik packages to update package.json file of the generated application with file:path-to-package.tgz.

  4. Runs actual tests. Please pay attention at the beforeAll hook in the spec file

typescript
beforeAll(() => {
  const config = scaffoldQwikProject();
  global.tmpDir = config.tmpDir;

  return async () => {
    await killAllRegisteredProcesses();
    config.cleanupFn();
  };
});

Notice that beforeAll returns a function, which will be executed after the test completes either with success or failure.

Both config.cleanupFn(); and killAllRegisteredProcesses there are extremely important:

  • config.cleanupFn() is used in order to remove temporary folder with generated project after the test is executed (again, it's not being removed if TEMP_E2E_PATH is provided).
  • killAllRegisteredProcesses should be used to remove any active ports as we are serving the app during the test execution.
    Processes are being registered internally when runCommandUntil is executed. If you're executing something manually, you can use registerExecutedChildProcess utility to register the process.
    Despite killAllRegisteredProcesses will kill all processes when test exists, it is also a good practice to kill the process manually within the it statement using await promisifiedTreeKill(yourChildProcess.pId, 'SIGKILL')

Adding new tests

Right now we have only one test file within this project. This means only one test application will be created and used, which is good from the execution time standpoint. If more files are added, it shouldn't potentially be a problem as we have fileParallelism: false set in the vite.config.ts, which means only one test will be executed at a time. This obviously slows down the execution time, but is safer, because we're working with a real file system.


File: packages/supabase-auth-helpers-qwik/README.md

@supabase/auth-helpers-qwik (BETA)

This submodule provides convenience helpers for implementing user authentication in Qwik applications.


File: packages/qwik-react/README.md

Qwik qwik-react โšก๏ธ

  • Create a component library
  • Vite.js tooling.
  • Prettier code formatter.

Development Builds

Client only

During development, the index.html is not a result of server-side rendering, but rather the Qwik app is built using client-side JavaScript only. This is ideal for development with Vite and its ability to reload modules quickly and on-demand. However, this mode is only for development and does not showcase "how" Qwik works since JavaScript is required to execute, and Vite imports many development modules for the app to work.

text
npm run dev

Server-side Rendering (SSR) and Client

Server-side rendered index.html, with client-side modules prefetched and loaded by the browser. This can be used to test out server-side rendered content during development, but will be slower than the client-only development builds.

text
npm run dev.ssr

Production Builds

A production build should generate the client and server modules by running both client and server build commands.

text
npm run build

Client Modules

Production build that creates only the client-side modules that are dynamically imported by the browser.

text
npm run build.client

Server Modules

Production build that creates the server-side render (SSR) module that is used by the server to render the HTML.

text
npm run build.server