**What**
- Cleans up some artifacts from the V1 -> V2 migrations.
- Removes the MedusaProvider from the root in favor of a plain QueryClient.
- Applies font styles to make the text in admin resemble designs in Figma more closely.
**What**
- Moves all current route definitions to `v1.tsx`
- Creates a new `v2.tsx` file for future V2 routes.
- Updates RouteProvider to serve V1 or V2 routes based on if `MEDUSA_V2` is set.
**How to use it**
When working on V2 domains you should set `MEDUSA_V2=true` in `/packages/admin-next/dashboard/.env`. We can't use the Feature Flag in the Medusa project since there are breaking changes in the `/admin/store` endpoint between the two versions, so it needs to be managed manually.
**For people implementing V2 domains**
To add a new route you should:
- Add the route component in `/v2-routes`
- Define which path will render it in `v2.tsx`.
I would prefer that we don't try to implement a lot of conditional code that will make the codebase unnecessarily complex. So if I was to implement the V2 login page, I would copy/past the v1 login route into `v2-routes`, make the required changes, eg. replace `useAdminLogin` with `useAdminCustomPost(...)`, instead of trying to force the current V1 Login page to work with both APIs.
There will hopefully be a lot of components/sections from each domain that is re-usable between versions. As an example if you are working on the Product details page for V2 you might want to reuse the `product-general-section.tsx` file, as it works without having to make any modifications. In that case I propose that we create a `modules/product` folder and move the component in there which we can them import into both the v1 and v2 version of the route.
**What**
- Move packages for `next` version of admin to core repo
**Other**
- Since this PR introduces packages that depend on Vite 5, it also introduces @types/node@^20. We have never had a direct dependency on the types package for Node, and as far as I can see that has resulted in us using the types from Node.js@8, as those are a dependency of one of our dependencies. With the introduction of @types/node@^20, two of our packages had TS errors because they were using the NodeJS.Timer type, which was deprecated in Node.js@14. We should add specific @types/node packages to all our packages, but I haven't done so in this PR to keep it as clean as possible.
- Q: @olivermrbl I've added the new packages to the ignore list for changeset, is this enough to prevent them from being published?
