-
Notifications
You must be signed in to change notification settings - Fork 213
Fix struct duplication between internal/model and tools/publisher #240
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
Conversation
@domdomegg - It's alright, no worries 🍻 I'll make sure to address your feedback and rebase it 👍 |
Signed-off-by: Radoslav Dimitrov <[email protected]>
56d1a0d
to
fefb5ca
Compare
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
Signed-off-by: Radoslav Dimitrov <[email protected]>
fefb5ca
to
a0123ba
Compare
@domdomegg - hey, I don't have the rights to mark the PR out of draft and edit the PR description so I'll place it as a comment here - Motivation and Context• Remove duplicated structs in What’s changed• Switched publisher to import Example output{
"name": "io.github.example/simple-server",
"description": "A simple MCP server",
"status": "active",
"repository": {
"url": "https://github.com/example/simple-server",
"source": "github",
"id": ""
},
"version_detail": {
"version": "1.0.0"
},
"packages": [
{
"registry_name": "npm",
"name": "io.github.example/simple-server",
"version": "1.0.0",
"runtime_hint": "npx"
}
]
} How Has This Been Tested?• Built the publisher and generated a sample server.json; verified unset fields are omitted where omitempty is present. Breaking Changes• None. Types of changes• Refactor / code hygiene. Related• Add omitempty to repository.id or introduce a minimal DTO for publisher output to prevent accidental inclusion of registry-managed fields (already addressed via #285) |
Regarding this #217 (review) comment - I assume now that we have the |
Yep I think this is correct! I think also because of the extensions spec that we've agreed on the model can be exactly the same between publisher and registry :) |
@domdomegg - hey, fyi I'll work on rebasing this and do some housekeeping like better variable names this evening 👍 One of my goals is to have the server and the API objects public (as part of pkg/) and not be internal. |
Closing in favour of #318 (@domdomegg can you help with that as GitHub doesn't let me do it) |
<!-- Provide a brief summary of your changes --> ## Motivation and Context <!-- Why is this change needed? What problem does it solve? --> The following PR eliminates duplicate struct definitions by migrating the publisher tool to use canonical types from pkg/model, creating a single source of truth across the codebase. The publisher tool previously had its own copies of structs that were duplicated, ie. ServerJSON, Package, Repository, VersionDetail, EnvironmentVariable, RuntimeArgument and a few others which was not optimal **Changes in the PR:** - Refactored the structs to single canonical types located at pkg/model - Refactor the implementation to use/build canonical structures directly - Remove all duplicate definitions (5 structs eliminated) - Publisher now uses model.ServerJSON, model.Package, model.Repository, etc. - Renamed some of the structs to better reflect their use case, i.e. ServerJSON instead of ServerDetail - Fixes an issue where the Remote property was missing from the previous publisher copy of the Server **Benefits:** - Single source of truth - Schema changes in one place - Type safety - Compiler catches mismatches - Enhanced validation - Field constraints and bson tags - Zero breaking changes - Same CLI interface and JSON output - Future-proof - New canonical fields automatically available Supersedes: #217 and #240 ## How Has This Been Tested? <!-- Have you tested this in a real application? Which scenarios were tested? --> Locally ## Breaking Changes <!-- Will users need to update their code or configurations? --> No ## Types of changes <!-- What types of changes does your code introduce? Put an `x` in all the boxes that apply: --> - [x] Bug fix (non-breaking change which fixes an issue) - [ ] New feature (non-breaking change which adds functionality) - [ ] Breaking change (fix or feature that would cause existing functionality to change) - [ ] Documentation update ## Checklist <!-- Go over all the following points, and put an `x` in all the boxes that apply. --> - [ ] I have read the [MCP Documentation](https://modelcontextprotocol.io) - [ ] My code follows the repository's style guidelines - [ ] New and existing tests pass locally - [ ] I have added appropriate error handling - [ ] I have added or updated documentation as needed ## Additional context <!-- Add any other context, implementation notes, or design decisions --> --------- Signed-off-by: Radoslav Dimitrov <[email protected]>
…contextprotocol#318) <!-- Provide a brief summary of your changes --> <!-- Why is this change needed? What problem does it solve? --> The following PR eliminates duplicate struct definitions by migrating the publisher tool to use canonical types from pkg/model, creating a single source of truth across the codebase. The publisher tool previously had its own copies of structs that were duplicated, ie. ServerJSON, Package, Repository, VersionDetail, EnvironmentVariable, RuntimeArgument and a few others which was not optimal **Changes in the PR:** - Refactored the structs to single canonical types located at pkg/model - Refactor the implementation to use/build canonical structures directly - Remove all duplicate definitions (5 structs eliminated) - Publisher now uses model.ServerJSON, model.Package, model.Repository, etc. - Renamed some of the structs to better reflect their use case, i.e. ServerJSON instead of ServerDetail - Fixes an issue where the Remote property was missing from the previous publisher copy of the Server **Benefits:** - Single source of truth - Schema changes in one place - Type safety - Compiler catches mismatches - Enhanced validation - Field constraints and bson tags - Zero breaking changes - Same CLI interface and JSON output - Future-proof - New canonical fields automatically available Supersedes: modelcontextprotocol#217 and modelcontextprotocol#240 <!-- Have you tested this in a real application? Which scenarios were tested? --> Locally <!-- Will users need to update their code or configurations? --> No <!-- What types of changes does your code introduce? Put an `x` in all the boxes that apply: --> - [x] Bug fix (non-breaking change which fixes an issue) - [ ] New feature (non-breaking change which adds functionality) - [ ] Breaking change (fix or feature that would cause existing functionality to change) - [ ] Documentation update <!-- Go over all the following points, and put an `x` in all the boxes that apply. --> - [ ] I have read the [MCP Documentation](https://modelcontextprotocol.io) - [ ] My code follows the repository's style guidelines - [ ] New and existing tests pass locally - [ ] I have added appropriate error handling - [ ] I have added or updated documentation as needed <!-- Add any other context, implementation notes, or design decisions --> --------- Signed-off-by: Radoslav Dimitrov <[email protected]>
I sincerely apologize for the disruption. This PR was accidentally closed due to an unintended git history rewrite operation that broke the connection between branches. The operation has been reverted and I'm now recreating the affected PRs.\n\nOriginal PR: #217