deepkit / deepkit-framework

A new full-featured and high-performance TypeScript framework
https://deepkit.io/
MIT License
3.14k stars 116 forks source link

Simplify the setup of the workspaces. #303

Open JumpLink opened 1 year ago

JumpLink commented 1 year ago

It's hard for me to build and test the packages when I make changes.

Maybe it makes sense to switch to Yarn Berry (v3) in the future, with Yarn it is possible to automatically link to the packages in your own workspace so that they are not overwritten during an install. In addition, the versions of the internal package dependencies are automatically resolved during a yarn npm publish, so npm-local-development is no longer needed.

Maybe Yarn could also replace Lerna, but can also be used together with Yarn.

marcj commented 1 year ago

It's hard for me to build and test the packages when I make changes.

What doesn't work? Let me know what is the issue and we can fix it.

Yarn/npm workspaces and Lerna have all in common that they link the whole package which is broken by design since that would not allow us to install devDependencies at the same time (it would resolve the wrong package otherwise). That's why we use npm-local-development.

JumpLink commented 1 year ago

What doesn't work?

@marcj It's more the workflow that is not good, there are just a lot of problems that can occur, things we have also discussed in discord, e.g.

yarn also comes with some useful tools and plugins that can replace lerna and 'npm-local-development', then we have only one tool for the workspaces, but yarn would also work together with lerna.

that would not allow us to install devDependencies

Maybe I don't understand the problem correctly, but with yarn >= 2 you can do the following:

{
  "name": "@deepkit/http",
  "dependencies": {
    "@deepkit/api-console-module": "workspace:^",
    "@deepkit/app": "workspace:^",
    "@deepkit/bson": "workspace:^",
    ...
  },
}

As soon as you publish the package with yarn npm publish, yarn will replace workspace:^ with the version string of the package in your workspace.

This way you can determine exactly what should be used from the workspace and what not, also in the devDependencies.

Alternatively you can force to use the workspace package in the root package.json, even if there is a different version defined in a workspace package package.json:

{
  "name": "root",
  "resolutions": {
    "@deepkit/core": "workspace:^",
    "@deepkit/event": "workspace:^",
    "@deepkit/stopwatch": "workspace:^",
    "@deepkit/workflow": "workspace:^",
    "@deepkit/app": "workspace:^",
    "@deepkit/injector": "workspace:^",
    "@deepkit/type": "workspace:^",
    "@deepkit/type-compiler": "workspace:^",
    "@deepkit/type-spec": "workspace:^",
    ...
  }
}

it would resolve the wrong package otherwise

I do not understand how this would resolve to the wrong devDependencies, can you explain this more?