QwikDev / qwik

Instant-loading web apps, without effort
https://qwik.dev
MIT License
20.44k stars 1.26k forks source link

Enhance Qwik CLI to allow migrating automatically from Qwik 1 the Qwik 2 #6573

Open GregOnNet opened 1 week ago

GregOnNet commented 1 week ago

Story

To make the experience migrating from Qwik 1.x to version 2, a developer should be able to do it with one single command.

Goal

Tasks of the migration command

Migration Process

[!NOTE] The Angular CLI or NX download the newest version of the CLI before they execute updates and migrations to get the most recent updated. Since we start with this project, we require the developer to update Qwik manually to receive the migration command. Downloading a newer Version of Qwik and then executing the update, might be out-of-scope for us.

flowchart TD
    A[npm install @builder.io/qwik@^1] -->|Get version of Qwik providing migration command| B(qwik migrate-v2)
    B --> C{Execute Migration}
    C -->|Update scope in project| D[@builder.io => @qwikdev]
    C -->|Update Qwik dependencies| E["`
                @types/eslint
                @types/node
                @typescript-eslint/eslint-plugin
                @typescript-eslint/parser
                eslint
                eslint-plugin-qwik
                prettier
                typescript
                undici
                vite
                vite-tsconfig-paths
              `"]
   D & E--> L{{🎊 Complete Migration by telling a joke?}}

The chart illustrates the migration process

  1. Install the most recent version of Qwik 1.x to get the migration command
  2. Execute migration command
  3. Rename the package scope from @builder.io to @qwikdev
  4. Update Qwik's dependencies in package.json

🧪 integration tests

vite.config.ts

-  import { qwikCity } from '@builder.io/qwik-city/vite';
+ import { qwikCity } from '@qwikdev/qwik-city/vite';

tsconfig.json

-  "jsxImportSource": "@builder.io/qwik",
+ "jsxImportSource": "@qwikdev/qwik",

entry.dev.ts

- import type { RenderOptions } from '@builder.io/qwik';
+import type { RenderOptions } from '@qwikdev/qwik'; // ❓ @qwik/core?

entry.preview.ts

- import { createQwikCity } from '@builder.io/qwik-city/middleware/node';
+ import { createQwikCity } from '@qwikdev/qwik-city/middleware/node';  // ❓ What to do with deep imports? 

entry.ssr.ts

- import type { RenderToStreamOptions } from '@builder.io/qwik/server';
+ import type { RenderToStreamOptions } from '@qwikdev/qwik/server';  // ❓ Do we have sub-packages like this?
+ import type { RenderToStreamOptions } from '@qwikdev/server'; // 💡 Alternative would be @qwik/server
- import { renderToStream } from '@builder.io/qwik/server';
+import { renderToStream } from '@qwikdev/qwik/server'; 

root.tsx

- import {  QwikCityProvider,  RouterOutlet,  ServiceWorkerRegister} from '@builder.io/qwik-city';
+ import {  QwikCityProvider,  RouterOutlet,  ServiceWorkerRegister} from '@qwikdev/qwik-city';

component$

- import { component$ } from '@builder.io/qwik';
+ import { component$ } from '@qwikdev/qwik';
- import { $, component$, useSignal, useStyles$ } from '@builder.io/qwik';
+ import { $, component$, useSignal, useStyles$ } from '@qwikdev/qwik';
- import type { QRL } from '@builder.io/qwik';
+ import type { QRL } from '@qwikdev/qwik';
- import { component$ } from '@builder.io/qwik';
+ import type { QRL } from '@qwikdev/qwik';
GregOnNet commented 1 week ago

Hey @shairez ,

Dmitriy told me about the renamings: @builder.io/ to @qwikdev/ (@qwikdev/qwik, @qwikdev/qwik-city etc)

To me @qwikdev/qwik has redundancies. 2 times qwik. Personally, I would prefer @qwik-dev over qwikdev, too. But if it was decided by the team I can live with it.

Did you discussed further renamings for the future to have cleaner package-names?

cc @dmitry-stepanenko

GregOnNet commented 1 week ago

Discussed with @shairez The package name is still debatable.

@qwikdev/qwik could still become @qwikdev/core.

cc @dmitry-stepanenko

shairez commented 1 week ago

So we have a couple of options here:

For org names: @QwikDev/ @qwik-dev/ @qwik.dev/ (like the website)

For packages: (let's say with @QwikDev/ as a prefix: @QwikDev/core @QwikDev/qwik

GregOnNet commented 1 week ago

@qwik.dev/core is good to read.

I am concerned if a . in a scope-Name comes with trade-offs. 🤔 But we already have it in @builder.io. Maybe there are no problems to worry about.

GregOnNet commented 1 week ago

Hi @shairez,

currently, Qwik 1.x exposes sub-packages, e.g @builder.io/qwik/server. Will Qwik 2 preserve the existing package-structure, or do we plan changes in that area, too?

Could @builder.io/qwik/server become @builder.io/server?

I am asking, because we want to know if we just replace the scope-name or if we need to be capable of replacing whole import paths.

GregOnNet commented 1 week ago

@dmitry-stepanenko Do you know if all Qwik dependencies are mentioned in the chart that need to be updated?

dmitry-stepanenko commented 1 week ago

I also think that @qwik.dev/core is the best option among others.

I also think that we should name the CLI command qwik migrate-v2 instead of just qwik migrate, as I'd preserve the latter for real migration capabilities that we could prepare at a later point.

Will Qwik 2 preserve the existing package-structure, or do we plan changes in that area, too?

V2 seems to not have any changes to the structure, thus imports like @builder.io/qwik/server are still in place. And I'd doubt we should make any changes like @builder.io/server, because that would mean creating a separate package for things that are used internally in existing package and are not supposed to work separately. Like angular's way of distributing the framework with 10+ packages is a bit of an overkill IMO

Do you know if all Qwik dependencies are mentioned in the chart that need to be updated?

Dependency upgrade will consist of 3 parts:

While bumping dependencies we should make sure we don't override those that are higher than what we'll be installing

Along with that it also makes sense to upgrade all internal integrations that qwik supports (things like qwik-react, qwik-worker etc). Probably it will be the best to check for integration existence and update corresponding names/files using separated logic.

GregOnNet commented 1 week ago

Would we need to check for the used node-version in order to install the correct @types/node package?

GregOnNet commented 1 week ago

I started looking where we need to extend the existing CLI. Here is something related to qwik add: https://github.com/QwikDev/qwik/blob/fcb56b0391a02493af72dca84af9f7fae538a2c3/packages/create-qwik/src/helpers/logAppCreated.ts#L25