-
Notifications
You must be signed in to change notification settings - Fork 1.5k
[v2] Мonorepo, sdk-client, sdk-server, sdk-core package split
#1279
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
[v2] Мonorepo, sdk-client, sdk-server, sdk-core package split
#1279
Conversation
commit: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a way we can break this PR up somehow so that this is more reviewable? E.g. with using git mv to preserve history and provenance of files? As it is it'll be quite hard to verify correctness of the split.
… into feature/v2-monorepo-setup
|
EDITs:
TODOs still:
|
sdk-client, sdk-server, sdk-core package split
… into feature/v2-monorepo-setup
…typescript-sdk into feature/v2-monorepo-setup
… into feature/v2-monorepo-setup
|
I would push against removing tsgo from the check script. As we move to a monorepo it will be much much faster than tsc. |
| export default defineConfig({ | ||
| // 1. Entry Points | ||
| // Directly matches package.json include/exclude globs | ||
| entry: ['src/**/*.ts', '!src/**/*.test.ts', '!src/__mocks__/**', '!src/examples/**'], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this should just be the root index.ts
| "node": ">=20", | ||
| "pnpm": ">=10.24.0" | ||
| }, | ||
| "packageManager": "[email protected]", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I dont hate this move. I like that we wont have to use turborepo or nx, at least initially. But it should be noted this will be a big dev ex change
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, we would need to update the README and the contribution guidelines
| @@ -0,0 +1,3 @@ | |||
| import { defineWorkspace } from 'vitest/config'; | |||
|
|
|||
| export default defineWorkspace(['packages/**/vitest.config.js']); | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I did not know this was a thing lol. why do we need this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Basically different configs if we need to - https://v2.vitest.dev/guide/workspace
| export default defineConfig({ | ||
| // 1. Entry Points | ||
| // Directly matches package.json include/exclude globs | ||
| entry: ['src/**/*.ts', '!src/**/*.test.ts', '!src/__mocks__/**', '!src/examples/**'], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this should just be the index.ts also. Note there are other options: this config can also live in the package.json for each package or can be defined at root and imported here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tks, will update
| export * from './validation/ajv-provider.js'; | ||
| export * from './validation/cfworker-provider.js'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
these have to be exported in the package.json. otherwise they will both get included on import.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
really we should use shims for this in the package.json and not have separate modules. similarly to this. mswjs/msw#2640
| "rootDir": "./src" | ||
| }, | ||
| "include": ["./"], | ||
| "exclude": ["dist", "node_modules", "test"] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we should not need seperate build tsconfigs. that is the beauty of tsdown.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, this is leftover from before I added tsdown, will remove, tks
| "@modelcontextprotocol/sdk-client": ["node_modules/@modelcontextprotocol/sdk-client/src/index.ts"], | ||
| "@modelcontextprotocol/sdk-server": ["node_modules/@modelcontextprotocol/sdk-server/src/index.ts"], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
are these used? that would make for a weird dependency structure?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Its a leftover thing, tks, will clean up
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
its weird that these examples live in packages. maybe put examples on the top level?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think going forward, it'd be good to treat examples as real end-user scenarios, them being in a package and importing our real packages simulates that quite well - let's discuss
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
also feels pretty weird that this is a package. imo these tests should live in either client or server depending on what they are testing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
you could have some test helpers but they would live in common.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, this one felt weird to me as well and haven't spent a lot of time thinking about it.
Let's think how we want it and refactor in a separate PR.
Proof of Concept: v2 monorepo, package split
Motivation and Context
v1of the sdk shipped both client and server in the same package, introducing extra dependencies to users who have a single concern (client or server only). Client and server packages are now split, depending on a sharedcorepackage.Additionally,
v1exported all files as the public API of the SDK, limiting the SDK ability to iterate internally while keeping backwards compatibility. Barrel files are now introduced as the single entrypoint to the SDK and defining the public API of the SDK.How Has This Been Tested?
Unit, integration tests
Breaking Changes
v2
Types of changes
Checklist
Additional context