Add comprehensive README documentation for all sub-packages#129
Add comprehensive README documentation for all sub-packages#129huangyiirene merged 3 commits intomainfrom
Conversation
Co-authored-by: huangyiirene <7665279+huangyiirene@users.noreply.github.com>
Co-authored-by: huangyiirene <7665279+huangyiirene@users.noreply.github.com>
There was a problem hiding this comment.
Pull request overview
This PR updates documentation across the ObjectQL monorepo by creating a comprehensive README for @objectql/platform-node and reorganizing the main README's architecture section with improved structure and navigation.
Changes:
- Created a complete 501-line README for
@objectql/platform-nodewith API documentation, examples, and best practices - Reorganized main README architecture into four logical layers (Foundation, Driver, Runtime, Tools) with hyperlinks to package READMEs
- Expanded package listings from 8 to 15 packages with consistent descriptions
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.
| File | Description |
|---|---|
| packages/foundation/platform-node/README.md | New comprehensive documentation for Node.js platform utilities package |
| README.md | Restructured architecture section with categorized layers and expanded package listings |
|
|
||
| - Match file names to object names: `user.object.yml` for object "user" | ||
| - Use singular names: `project`, not `projects` | ||
| - Use lowercase with underscores: `project_task`, not `ProjectTask` |
There was a problem hiding this comment.
The naming convention guidance contradicts ObjectQL's standard practice. Based on the codebase context, ObjectQL object names should use snake_case (lowercase with underscores), which is correctly stated. However, the example should clarify that this applies to object names in YAML files, not TypeScript class names which typically use PascalCase.
| Create custom handlers for specialized file types: | ||
|
|
||
| ```typescript | ||
| import { LoaderPlugin } from '@objectql/types'; |
There was a problem hiding this comment.
According to the architectural rules in the coding guidelines, @objectql/types should contain pure TypeScript interfaces, enums, and custom errors with zero dependencies. Verify that LoaderPlugin interface actually exists in @objectql/types. Based on the architecture, platform-specific types like LoaderPlugin might belong in @objectql/platform-node instead, as it's specific to the Node.js file system loading implementation.
| import { | ||
| ObjectLoader, | ||
| LoaderPlugin, | ||
| LoaderHandlerContext, | ||
| loadPlugin | ||
| } from '@objectql/platform-node'; |
There was a problem hiding this comment.
This import example shows LoaderPlugin and LoaderHandlerContext being imported from @objectql/platform-node, which contradicts line 258 that imports LoaderPlugin from @objectql/types. Ensure consistent import sources throughout the documentation. Based on the architecture guidelines, these platform-specific types should come from @objectql/platform-node.
|
The monorepo lacked documentation coverage for the
@objectql/platform-nodepackage and the main README's architecture section needed reorganization to surface all 15 packages clearly.Changes
Created missing package documentation:
@objectql/platform-nodecovering file system metadata loading, plugin system, and module discoveryRestructured main README architecture section:
Coverage:
types,core,platform-nodesql,mongo,memory,localstorage,fs,excel,redis,sdkservercli,create,vscode-objectqlThe architecture section now provides a complete navigable map of the monorepo structure.
Original prompt
💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.