Open GregOnNet opened 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
Discussed with @shairez The package name is still debatable.
@qwikdev/qwik
could still become @qwikdev/core
.
cc @dmitry-stepanenko
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
@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.
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.
@dmitry-stepanenko Do you know if all Qwik dependencies are mentioned in the chart that need to be updated?
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:
@builder.io/qwik
& @builder.ioqwik-city
packages@qwik.dev/qwik
& @qwik.dev/qwik-city
packages (assuming the new name is @qwik.dev/*
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.
Would we need to check for the used node-version in order to install the correct @types/node
package?
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
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
@builder.io
toqwikdev
(the name qwikdev is still discussed internally).Migration Process
qwik migrate-v2
The chart illustrates the migration process
@builder.io
to@qwikdev
package.json
🧪 integration tests
vite.config.ts
tsconfig.json
entry.dev.ts
entry.preview.ts
entry.ssr.ts
root.tsx
component$