feat(platform-fastify): add Fastify platform #2925
Conversation
WalkthroughThis pull request introduces a comprehensive implementation of the Changes
Sequence DiagramsequenceDiagram
participant Client
participant PlatformFastify
participant Server
participant Router
participant Middleware
participant Controller
Client->>PlatformFastify: HTTP Request
PlatformFastify->>Server: Create Fastify Instance
Server->>Router: Register Routes
Router->>Middleware: Apply Middleware
Middleware->>Controller: Invoke Handler
Controller-->>Middleware: Return Response
Middleware-->>Router: Process Response
Router-->>Server: Send Response
Server-->>Client: HTTP Response
This sequence diagram illustrates the request processing flow in the new Fastify platform implementation, showing how requests are routed, middleware is applied, and responses are generated. ✨ Finishing Touches
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 38
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
⛔ Files ignored due to path filters (1)
yarn.lockis excluded by!**/yarn.lock,!**/*.lock
📒 Files selected for processing (25)
packages/platform/platform-fastify/.npmignore(1 hunks)packages/platform/platform-fastify/package.json(1 hunks)packages/platform/platform-fastify/readme.md(1 hunks)packages/platform/platform-fastify/src/components/PlatformFastify.spec.ts(1 hunks)packages/platform/platform-fastify/src/components/PlatformFastify.ts(1 hunks)packages/platform/platform-fastify/src/exports.ts(1 hunks)packages/platform/platform-fastify/src/index.ts(1 hunks)packages/platform/platform-fastify/src/interfaces/PlatformFastifySettings.ts(1 hunks)packages/platform/platform-fastify/src/interfaces/interfaces.ts(1 hunks)packages/platform/platform-fastify/src/services/PlatformFastifyRequest.spec.ts(1 hunks)packages/platform/platform-fastify/src/services/PlatformFastifyRequest.ts(1 hunks)packages/platform/platform-fastify/src/services/PlatformFastifyResponse.spec.ts(1 hunks)packages/platform/platform-fastify/src/services/PlatformFastifyResponse.ts(1 hunks)packages/platform/platform-fastify/test/app/Server.ts(1 hunks)packages/platform/platform-fastify/test/app/index.ts(1 hunks)packages/platform/platform-fastify/test/app/public/index.html(1 hunks)packages/platform/platform-fastify/test/app/views/view.ejs(1 hunks)packages/platform/platform-fastify/test/platform-fastify.spec.ts(1 hunks)packages/platform/platform-fastify/tsconfig.esm.json(1 hunks)packages/platform/platform-fastify/tsconfig.json(1 hunks)packages/platform/platform-fastify/tsconfig.spec.json(1 hunks)packages/platform/platform-fastify/vitest.config.mts(1 hunks)packages/platform/platform-router/src/domain/PlatformHandlerMetadata.spec.ts(6 hunks)packages/platform/platform-router/src/domain/PlatformHandlerMetadata.ts(1 hunks)tsconfig.json(1 hunks)
🧰 Additional context used
🪛 LanguageTool
packages/platform/platform-fastify/readme.md
[style] ~49-~49: Using many exclamation marks might seem excessive (in this case: 7 exclamation marks for a text that’s 2441 characters long)
Context: ...## Backers Thank you to all our backers! 🙏 [[Become a backer](https://opencolle...
(EN_EXCESSIVE_EXCLAMATION)
[typographical] ~61-~61: If you want to indicate numerical ranges or time ranges, consider using an en dash.
Context: ...he MIT License (MIT) Copyright (c) 2016 - 2018 Romain Lenzotti Permission is here...
(DASH_RULE)
🪛 Markdownlint (0.35.0)
packages/platform/platform-fastify/readme.md
1-1: Element: p
Inline HTML
(MD033, no-inline-html)
2-2: Element: a
Inline HTML
(MD033, no-inline-html)
2-2: Element: img
Inline HTML
(MD033, no-inline-html)
5-5: Element: div
Inline HTML
(MD033, no-inline-html)
6-6: Element: h1
Inline HTML
(MD033, no-inline-html)
19-19: Element: div
Inline HTML
(MD033, no-inline-html)
20-20: Element: a
Inline HTML
(MD033, no-inline-html)
21-21: Element: span
Inline HTML
(MD033, no-inline-html)
22-22: Element: a
Inline HTML
(MD033, no-inline-html)
23-23: Element: span
Inline HTML
(MD033, no-inline-html)
24-24: Element: a
Inline HTML
(MD033, no-inline-html)
25-25: Element: span
Inline HTML
(MD033, no-inline-html)
26-26: Element: a
Inline HTML
(MD033, no-inline-html)
29-29: Element: hr
Inline HTML
(MD033, no-inline-html)
45-45: Element: a
Inline HTML
(MD033, no-inline-html)
45-45: Element: img
Inline HTML
(MD033, no-inline-html)
51-51: Element: a
Inline HTML
(MD033, no-inline-html)
51-51: Element: img
Inline HTML
(MD033, no-inline-html)
31-31: null
Bare URL used
(MD034, no-bare-urls)
1-1: null
First line in a file should be a top-level heading
(MD041, first-line-heading, first-line-h1)
45-45: null
Images should have alternate text (alt text)
(MD045, no-alt-text)
51-51: null
Images should have alternate text (alt text)
(MD045, no-alt-text)
🪛 Biome (1.9.4)
packages/platform/platform-fastify/src/interfaces/interfaces.ts
[error] 7-7: Don't use 'Function' as a type.
Prefer explicitly define the function shape. This type accepts any function-like value, which can be a common source of bugs.
(lint/complexity/noBannedTypes)
packages/platform/platform-fastify/src/services/PlatformFastifyResponse.ts
[error] 4-4: A Node.js builtin module should be imported with the node: protocol.
Using the node: protocol is more explicit and signals that the imported module belongs to Node.js.
Unsafe fix: Add the node: protocol.
(lint/style/useNodejsImportProtocol)
packages/platform/platform-fastify/src/services/PlatformFastifyRequest.ts
[error] 3-3: A Node.js builtin module should be imported with the node: protocol.
Using the node: protocol is more explicit and signals that the imported module belongs to Node.js.
Unsafe fix: Add the node: protocol.
(lint/style/useNodejsImportProtocol)
packages/platform/platform-fastify/src/components/PlatformFastify.ts
[error] 24-24: A Node.js builtin module should be imported with the node: protocol.
Using the node: protocol is more explicit and signals that the imported module belongs to Node.js.
Unsafe fix: Add the node: protocol.
(lint/style/useNodejsImportProtocol)
[error] 158-158: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 114-114: Don't use 'Function' as a type.
Prefer explicitly define the function shape. This type accepts any function-like value, which can be a common source of bugs.
(lint/complexity/noBannedTypes)
[error] 121-121: Don't use 'Function' as a type.
Prefer explicitly define the function shape. This type accepts any function-like value, which can be a common source of bugs.
(lint/complexity/noBannedTypes)
[error] 130-130: Don't use 'Function' as a type.
Prefer explicitly define the function shape. This type accepts any function-like value, which can be a common source of bugs.
(lint/complexity/noBannedTypes)
[error] 314-314: Reassigning a function parameter is confusing.
The parameter is declared here:
Use a local variable instead.
(lint/style/noParameterAssign)
🔇 Additional comments (14)
packages/platform/platform-fastify/tsconfig.esm.json (2)
1-2: LGTM! Good use of base configuration.
Extending from @tsed/typescript/tsconfig.node.json ensures consistent TypeScript settings across the monorepo and properly configures Node.js-specific settings.
12-25: Verify test helper exclusion and webpack configuration.
The include/exclude patterns look comprehensive, but let's verify two things:
- That no test helpers in
srcare accidentally included - Whether webpack configuration should also exclude
.tsvariants
✅ Verification successful
Include/exclude patterns in tsconfig.esm.json are correctly configured
The verification shows:
- No test helpers were found in the src directory that might be accidentally included
- The webpack.config.js exclusion is sufficient as there's no webpack.config.ts in this package
The current configuration correctly excludes test files and build artifacts while including the necessary source files.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check for potential test helpers in src directory
echo "Checking for test helpers in src..."
fd -e ts -E "*.spec.ts" . "src" | grep -i "test\|mock\|stub\|fake"
# Check for webpack config variants
echo "Checking for webpack config variants..."
fd "webpack.config" . | grep -v "\.js$"
Length of output: 678
Script:
#!/bin/bash
# Adjust the path to check for test helpers in the correct package directory
echo "Checking for potential test helpers in platform-fastify src..."
fd -e ts -E "*.spec.ts" . "packages/platform/platform-fastify/src" | grep -i "test\|mock\|stub\|fake"
# Check webpack config in the specific package
echo "Checking webpack config in platform-fastify..."
fd "webpack.config" . "packages/platform/platform-fastify"
Length of output: 916
packages/platform/platform-fastify/src/services/PlatformFastifyRequest.ts (2)
53-57:
Ensure accepts() method is available in Fastify
The this.raw.accepts() method may not be available by default in Fastify. You need to register the @fastify/accepts plugin to provide this functionality.
Run the following script to check if the @fastify/accepts plugin is registered:
45-47: 🧹 Nitpick (assertive)
Simplify header retrieval by using this.raw.headers
Instead of accessing headers via this.raw.raw.headers, you can directly use this.raw.headers, which provides the same header information and improves readability.
Apply this diff to simplify the method:
-return this.raw.raw.headers[name.toLowerCase()];
+return this.raw.headers[name.toLowerCase()];Likely invalid or redundant comment.
packages/platform/platform-fastify/test/app/views/view.ejs (1)
1-1: LGTM! Template looks good.
The EJS template is properly structured and uses the correct syntax for variable interpolation. The built-in EJS escaping (<%=) provides protection against XSS attacks.
packages/platform/platform-fastify/src/exports.ts (1)
5-6: 🧹 Nitpick (assertive)
Verify platform adapter implementation.
While the adapter assignments are straightforward, it's important to ensure that PlatformFastify properly implements all required platform adapter interfaces.
Additionally, consider making the adapter assignment more explicit and type-safe:
-PlatformTest.adapter = PlatformFastify;
-PlatformBuilder.adapter = PlatformFastify;
+PlatformTest.setAdapter(PlatformFastify);
+PlatformBuilder.setAdapter(PlatformFastify);✅ Verification successful
Let me generate another script to specifically look for the PlatformFastify class implementation and its inheritance/implementation details:
This will help us verify if PlatformFastify properly implements the required platform adapter interfaces.
Let me search for the base PlatformAdapter class to understand the inheritance structure:
Based on the gathered information, I can now provide the final response:
PlatformFastify correctly implements the platform adapter interface
The code inspection shows that PlatformFastify properly extends the abstract PlatformAdapter class from @tsed/platform-http, which defines the required platform adapter interface. The implementation includes:
- Proper class inheritance:
class PlatformFastify extends PlatformAdapter<FastifyInstance> - Required abstract property implementation:
readonly NAME = "fastify" - Proper provider configuration through the
providersproperty
The static assignments in exports.ts are therefore type-safe and valid.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify PlatformFastify implements required interfaces
# Check for required interface definitions
ast-grep --pattern 'interface $INTERFACE { $$$ }' | grep -i 'platform'
# Check PlatformFastify class implementation
ast-grep --pattern 'class PlatformFastify $EXTENDS implements $IMPLEMENTS { $$$ }'
Length of output: 38331
Script:
#!/bin/bash
# Search for PlatformFastify class definition and its related base classes/interfaces
rg -A 5 "class PlatformFastify"
# Search for potential platform adapter interfaces
rg -A 3 "interface.*Platform.*Adapter"
Length of output: 1889
Script:
#!/bin/bash
# Search for PlatformAdapter class/interface definition
rg -A 10 "export (abstract )?class PlatformAdapter"
# Also check the imports in PlatformFastify
rg -A 5 "import.*PlatformAdapter"
Length of output: 7760
packages/platform/platform-fastify/src/index.ts (1)
4-9: Verify completeness of Fastify platform exports
The exports look organized, but let's ensure all essential Fastify platform components are covered.
✅ Verification successful
All essential Fastify platform components are properly exported
Based on the verification results:
- All Fastify-related TypeScript files are properly exported through the barrel file
- The exports cover all core components: Platform, Settings, Request, Response, and interfaces
- The
exports.tsfile correctly sets up platform adapters - No Fastify-related components are missing from the exports
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify if all essential Fastify components are exported and no files are missed
# Find all .ts files in the src directory
echo "=== TypeScript files in src ==="
fd -e ts . "packages/platform/platform-fastify/src"
# Check for any potential Fastify-related files that might be missing from exports
echo -e "\n=== Potential missing exports ==="
fd -e ts . "packages/platform/platform-fastify/src" -x grep -l "Fastify" {} \; | \
grep -v -f <(echo -e "PlatformFastify.ts\nPlatformFastifySettings.ts\nPlatformFastifyRequest.ts\nPlatformFastifyResponse.ts")
Length of output: 1160
Script:
#!/bin/bash
# Let's verify the exports more thoroughly
# First, check the content of exports.ts
echo "=== Content of exports.ts ==="
cat "packages/platform/platform-fastify/src/exports.ts"
# Then check for any TypeScript files that contain Fastify-related code
echo -e "\n=== Files containing Fastify references ==="
rg -l "Fastify" "packages/platform/platform-fastify/src"
# Finally, let's check the actual exports from these files
echo -e "\n=== Exports in Fastify-related files ==="
rg "^export " "packages/platform/platform-fastify/src" --type ts
Length of output: 3090
packages/platform/platform-fastify/vitest.config.mts (2)
1-2: 🛠️ Refactor suggestion
Remove @ts-ignore and fix typing issues
Instead of using @ts-ignore, we should properly type the imports.
-// @ts-ignore
-import {presets} from "@tsed/vitest/presets";
+import type {presets} from "@tsed/vitest/presets";Likely invalid or redundant comment.
9-18: Verify the feasibility of high coverage thresholds
The coverage thresholds are set very high and specific:
- statements: 99.15%
- branches: 95.6%
- functions: 100%
- lines: 99.15%
While high coverage is good, such specific thresholds might be hard to maintain.
✅ Verification successful
Let me gather more information about the test coverage by examining the actual test file and its contents.
The previous results show that there's a single test file and its corresponding implementation file. Let's analyze their contents to understand if the high coverage thresholds are justified based on the codebase complexity and test coverage.
Based on the analysis of both test and source files, I can now generate the final response:
High coverage thresholds are justified and maintainable
The high coverage thresholds are reasonable because:
- The test suite is comprehensive, covering all major platform features (24 test suites)
- The implementation is well-structured and uses a standardized adapter pattern
- Non-testable features (stream, view, statics, multer) are properly skipped
- The codebase follows a consistent pattern making it highly testable
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check current test coverage to verify if thresholds are realistic
# Find and analyze test files
echo "=== Test files coverage ==="
fd -e spec.ts -e test.ts . "packages/platform/platform-fastify/test"
# Check if all components have corresponding test files
echo -e "\n=== Components without test files ==="
for f in $(fd -e ts . "packages/platform/platform-fastify/src/components"); do
base=$(basename $f .ts)
if ! fd "${base}.spec.ts|${base}.test.ts" "packages/platform/platform-fastify/test" >/dev/null; then
echo "Missing tests for: $f"
fi
done
Length of output: 933
Script:
#!/bin/bash
# Check the content and complexity of the test file
echo "=== Test file content ==="
cat packages/platform/platform-fastify/test/platform-fastify.spec.ts
# Check the source file to understand what needs to be tested
echo -e "\n=== Source file content ==="
cat packages/platform/platform-fastify/src/components/PlatformFastify.ts
Length of output: 11726
packages/platform/platform-fastify/test/app/Server.ts (1)
21-32: Consider adding plugin version constraints
Plugin versions should be explicitly specified to prevent breaking changes.
packages/platform/platform-fastify/tsconfig.json (1)
7-7: Verify the empty include array configuration.
An empty include array might unintentionally exclude source files. Consider explicitly including source files:
- "include": [],
+ "include": ["src/**/*.ts", "src/**/*.tsx"]✅ Verification successful
Empty include array is correct for this TypeScript configuration
The empty include array in tsconfig.json is intentional and correct for this package because:
- The package uses
src/index.tsas the source entry point, as defined in package.json - The TypeScript files are properly organized under the
src/directory - The build process is managed through the
build:tsscript usingtsc --build tsconfig.json - The package extends from a base configuration
@tsed/typescript/tsconfig.node.jsonwhich likely contains the necessary include patterns
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check if there are any TypeScript files that might be excluded
fd -e ts -e tsx . src/
Length of output: 116
Script:
#!/bin/bash
# Let's first check the directory structure to understand where the TypeScript files are located
fd --type directory
# Then check for all TypeScript files in the repository
fd -e ts -e tsx
Length of output: 96052
Script:
#!/bin/bash
# Let's check if there are any TypeScript files in the platform-fastify directory
fd -e ts -e tsx . packages/platform/platform-fastify/
# Let's also check the package.json to understand the project structure
cat packages/platform/platform-fastify/package.json
Length of output: 3813
packages/platform/platform-fastify/test/platform-fastify.spec.ts (1)
6-10: Verify test coverage configuration
The test setup uses PlatformTestSdk with PlatformFastify adapter. Let's verify the test coverage settings.
✅ Verification successful
Test coverage thresholds are properly configured
The test coverage configuration is well-defined with high threshold requirements:
- Statements: 99.15%
- Branches: 95.6%
- Functions: 100%
- Lines: 99.15%
These are robust thresholds that ensure comprehensive test coverage for the platform-fastify package.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check for coverage configuration
echo "Checking coverage configuration..."
rg "coverage|threshold" packages/platform/platform-fastify/vitest.config.mts
Length of output: 231
Script:
#!/bin/bash
# Let's check the actual coverage thresholds and configuration
cat packages/platform/platform-fastify/vitest.config.mts
Length of output: 456
packages/platform/platform-router/src/domain/PlatformHandlerMetadata.ts (1)
142-144: LGTM! Clean implementation of raw middleware check
The implementation correctly combines the injectable check with raw function type verification, following the existing pattern of handler type checks in the class.
packages/platform/platform-router/src/domain/PlatformHandlerMetadata.spec.ts (1)
37-37: LGTM! Comprehensive test coverage for isRawMiddleware()
The test coverage for the new isRawMiddleware() method is thorough and well-structured, covering all important scenarios:
- Context handlers (false)
- Raw functions (true)
- Raw error functions (true)
- Endpoint/middleware with injection (false)
- Error middleware (false)
Also applies to: 54-54, 72-72, 91-91, 124-124, 152-152
| "compilerOptions": { | ||
| "baseUrl": ".", | ||
| "rootDir": "src", | ||
| "outDir": "./lib/esm", | ||
| "declarationDir": "./lib/types", | ||
| "declaration": true, | ||
| "composite": true, | ||
| "noEmit": false | ||
| }, |
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Consider adding ESM-specific compiler options.
While the current configuration is good, consider adding these ESM-specific options for better module resolution and debugging support:
{
"compilerOptions": {
"baseUrl": ".",
"rootDir": "src",
"outDir": "./lib/esm",
"declarationDir": "./lib/types",
"declaration": true,
"composite": true,
- "noEmit": false
+ "noEmit": false,
+ "moduleResolution": "node",
+ "sourceMap": true
},📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| "compilerOptions": { | |
| "baseUrl": ".", | |
| "rootDir": "src", | |
| "outDir": "./lib/esm", | |
| "declarationDir": "./lib/types", | |
| "declaration": true, | |
| "composite": true, | |
| "noEmit": false | |
| }, | |
| "compilerOptions": { | |
| "baseUrl": ".", | |
| "rootDir": "src", | |
| "outDir": "./lib/esm", | |
| "declarationDir": "./lib/types", | |
| "declaration": true, | |
| "composite": true, | |
| "noEmit": false, | |
| "moduleResolution": "node", | |
| "sourceMap": true | |
| }, |
There was a problem hiding this comment.
"@tsed/typescript/tsconfig.node.json" contient déjà ces options. est-ce que c'est nécessaire de les répéter ?
There was a problem hiding this comment.
@Romakita Vous avez tout à fait raison, les options "moduleResolution" et "sourceMap" sont déjà définies dans "@tsed/typescript/tsconfig.node.json". Il n'est donc pas nécessaire de les répéter dans "tsconfig.esm.json" à moins de vouloir les remplacer. Désolé pour la confusion.
✏️ Learnings added
Learnt from: Romakita
PR: tsedio/tsed#2925
File: packages/platform/platform-fastify/tsconfig.esm.json:3-11
Timestamp: 2024-12-10T17:46:27.526Z
Learning: Dans le projet Ts.ED, lorsqu'un fichier `tsconfig` comme `packages/platform/platform-fastify/tsconfig.esm.json` étend `"@tsed/typescript/tsconfig.node.json"`, il n'est pas nécessaire de répéter les options du compilateur telles que `"moduleResolution": "node"` et `"sourceMap": true`, car elles sont déjà incluses dans le fichier de configuration étendu.
Note: Learnings are effective only in the context of similar code segments. To apply general coding guidelines, please configure review instructions. You can manage existing learnings in the app.
packages/platform/platform-fastify/src/services/PlatformFastifyRequest.ts
Outdated
Show resolved
Hide resolved
packages/platform/platform-fastify/src/services/PlatformFastifyResponse.ts
Outdated
Show resolved
Hide resolved
packages/platform/platform-fastify/src/components/PlatformFastify.ts
Outdated
Show resolved
Hide resolved
| } from "@tsed/platform-http"; | ||
| import {PlatformHandlerMetadata, PlatformHandlerType, PlatformLayer} from "@tsed/platform-router"; | ||
| import Fastify, {FastifyInstance, FastifyReply, FastifyRequest} from "fastify"; | ||
| import {IncomingMessage, ServerResponse} from "http"; |
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Use 'node:' protocol when importing Node.js built-in modules
It's recommended to use the 'node:' protocol when importing Node.js built-in modules to make it explicit that the module belongs to Node.js.
Apply this diff to update the import statement:
-import {IncomingMessage, ServerResponse} from "http";
+import {IncomingMessage, ServerResponse} from "node:http";📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| import {IncomingMessage, ServerResponse} from "http"; | |
| import {IncomingMessage, ServerResponse} from "node:http"; |
🧰 Tools
🪛 Biome (1.9.4)
[error] 24-24: A Node.js builtin module should be imported with the node: protocol.
Using the node: protocol is more explicit and signals that the imported module belongs to Node.js.
Unsafe fix: Add the node: protocol.
(lint/style/useNodejsImportProtocol)
| "Koa", | ||
| "TypeScript", |
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Remove duplicate keyword "TypeScript"
The keywords array contains both "TypeScript" and "typescript" (case variants).
"keywords": [
"Koa",
"TypeScript",
- "typescript",
"Decorator",Committable suggestion skipped: line range outside the PR's diff.
| "peerDependencies": { | ||
| "@fastify/accepts": ">=4.3.0", | ||
| "@fastify/cookie": ">=9.3.1", | ||
| "@fastify/formbody": ">=7.4.0", | ||
| "@fastify/session": ">=10.7.0", | ||
| "@tsed/core": ">=8.0.0", | ||
| "@tsed/di": ">=8.0.0", | ||
| "@tsed/json-mapper": ">=8.0.0", | ||
| "@tsed/logger": ">=7.0.0", | ||
| "@tsed/openspec": ">=8.0.0", | ||
| "@tsed/platform-http": ">=8.0.0", | ||
| "@tsed/schema": ">=8.0.0", | ||
| "fastify": ">=5.1.0", | ||
| "fastify-raw-body": ">=5.0.0" | ||
| }, |
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Consider adding version upper bounds to peer dependencies
The current peer dependencies use >= which might lead to compatibility issues with future major versions. Consider using caret ranges (^) for better semver compatibility.
"peerDependencies": {
- "@fastify/accepts": ">=4.3.0",
+ "@fastify/accepts": "^4.3.0 || ^5.0.0",
- "@fastify/cookie": ">=9.3.1",
+ "@fastify/cookie": "^9.3.1 || ^10.0.0 || ^11.0.0",
// ... apply similar pattern to other dependenciesCommittable suggestion skipped: line range outside the PR's diff.
| ```bash | ||
| npm install --save @tsed/platform-fastify fastify | ||
| ``` |
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Enhance installation instructions
The installation section could be more comprehensive by including peer dependencies and configuration examples.
Consider adding:
- Optional dependencies installation
- Basic configuration example
- Common usage patterns
|
|
||
| The MIT License (MIT) | ||
|
|
||
| Copyright (c) 2016 - 2018 Romain Lenzotti |
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Update copyright year range
The copyright year range (2016 - 2018) appears outdated for this new package.
- Copyright (c) 2016 - 2018 Romain Lenzotti
+ Copyright (c) 2016 - 2024 Romain Lenzotti📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| Copyright (c) 2016 - 2018 Romain Lenzotti | |
| Copyright (c) 2016 - 2024 Romain Lenzotti |
🧰 Tools
🪛 LanguageTool
[typographical] ~61-~61: If you want to indicate numerical ranges or time ranges, consider using an en dash.
Context: ...he MIT License (MIT) Copyright (c) 2016 - 2018 Romain Lenzotti Permission is here...
(DASH_RULE)
| { | ||
| "path": "./packages/platform/platform-koa/tsconfig.json" | ||
| }, |
There was a problem hiding this comment.
Remove duplicate platform-koa reference and add platform-fastify
There are two issues with the TypeScript project references:
- The platform-koa reference appears twice (here and at line 148)
- The platform-fastify reference is missing, which should be added as part of this PR
Please apply these changes:
- Remove this duplicate entry
- Add the platform-fastify reference:
- {
- "path": "./packages/platform/platform-koa/tsconfig.json"
- },
+ {
+ "path": "./packages/platform/platform-fastify/tsconfig.json"
+ },📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| { | |
| "path": "./packages/platform/platform-koa/tsconfig.json" | |
| }, | |
| { | |
| "path": "./packages/platform/platform-fastify/tsconfig.json" | |
| }, |
Romakita
force-pushed
the
feat-fastify-v8
branch
2 times, most recently
from
74863e1 to
786b751
Compare
There was a problem hiding this comment.
Actionable comments posted: 15
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
⛔ Files ignored due to path filters (1)
yarn.lockis excluded by!**/yarn.lock,!**/*.lock
📒 Files selected for processing (27)
packages/platform/platform-fastify/.npmignore(1 hunks)packages/platform/platform-fastify/package.json(1 hunks)packages/platform/platform-fastify/readme.md(1 hunks)packages/platform/platform-fastify/src/components/PlatformFastify.spec.ts(1 hunks)packages/platform/platform-fastify/src/components/PlatformFastify.ts(1 hunks)packages/platform/platform-fastify/src/exports.ts(1 hunks)packages/platform/platform-fastify/src/index.ts(1 hunks)packages/platform/platform-fastify/src/interfaces/PlatformFastifySettings.ts(1 hunks)packages/platform/platform-fastify/src/interfaces/interfaces.ts(1 hunks)packages/platform/platform-fastify/src/services/PlatformFastifyRequest.spec.ts(1 hunks)packages/platform/platform-fastify/src/services/PlatformFastifyRequest.ts(1 hunks)packages/platform/platform-fastify/src/services/PlatformFastifyResponse.spec.ts(1 hunks)packages/platform/platform-fastify/src/services/PlatformFastifyResponse.ts(1 hunks)packages/platform/platform-fastify/test/app/Server.ts(1 hunks)packages/platform/platform-fastify/test/app/index.ts(1 hunks)packages/platform/platform-fastify/test/app/public/index.html(1 hunks)packages/platform/platform-fastify/test/app/views/view.ejs(1 hunks)packages/platform/platform-fastify/test/platform-fastify.spec.ts(1 hunks)packages/platform/platform-fastify/tsconfig.esm.json(1 hunks)packages/platform/platform-fastify/tsconfig.json(1 hunks)packages/platform/platform-fastify/tsconfig.spec.json(1 hunks)packages/platform/platform-fastify/vitest.config.mts(1 hunks)packages/platform/platform-http/src/common/decorators/params/request.spec.ts(1 hunks)packages/platform/platform-http/src/common/decorators/params/request.ts(1 hunks)packages/platform/platform-router/src/domain/PlatformHandlerMetadata.spec.ts(6 hunks)packages/platform/platform-router/src/domain/PlatformHandlerMetadata.ts(1 hunks)tsconfig.json(1 hunks)
🧰 Additional context used
📓 Learnings (1)
packages/platform/platform-fastify/tsconfig.esm.json (1)
Learnt from: Romakita
PR: tsedio/tsed#2925
File: packages/platform/platform-fastify/tsconfig.esm.json:3-11
Timestamp: 2024-12-10T17:46:27.733Z
Learning: Dans le projet Ts.ED, lorsqu'un fichier `tsconfig` comme `packages/platform/platform-fastify/tsconfig.esm.json` étend `"@tsed/typescript/tsconfig.node.json"`, il n'est pas nécessaire de répéter les options du compilateur telles que `"moduleResolution": "node"` et `"sourceMap": true`, car elles sont déjà incluses dans le fichier de configuration étendu.
🪛 LanguageTool
packages/platform/platform-fastify/readme.md
[style] ~49-~49: Using many exclamation marks might seem excessive (in this case: 7 exclamation marks for a text that’s 2441 characters long)
Context: ...## Backers Thank you to all our backers! 🙏 [[Become a backer](https://opencolle...
(EN_EXCESSIVE_EXCLAMATION)
[typographical] ~61-~61: If you want to indicate numerical ranges or time ranges, consider using an en dash.
Context: ...he MIT License (MIT) Copyright (c) 2016 - 2018 Romain Lenzotti Permission is here...
(DASH_RULE)
🪛 Markdownlint (0.35.0)
packages/platform/platform-fastify/readme.md
1-1: Element: p
Inline HTML
(MD033, no-inline-html)
2-2: Element: a
Inline HTML
(MD033, no-inline-html)
2-2: Element: img
Inline HTML
(MD033, no-inline-html)
5-5: Element: div
Inline HTML
(MD033, no-inline-html)
6-6: Element: h1
Inline HTML
(MD033, no-inline-html)
19-19: Element: div
Inline HTML
(MD033, no-inline-html)
20-20: Element: a
Inline HTML
(MD033, no-inline-html)
21-21: Element: span
Inline HTML
(MD033, no-inline-html)
22-22: Element: a
Inline HTML
(MD033, no-inline-html)
23-23: Element: span
Inline HTML
(MD033, no-inline-html)
24-24: Element: a
Inline HTML
(MD033, no-inline-html)
25-25: Element: span
Inline HTML
(MD033, no-inline-html)
26-26: Element: a
Inline HTML
(MD033, no-inline-html)
29-29: Element: hr
Inline HTML
(MD033, no-inline-html)
45-45: Element: a
Inline HTML
(MD033, no-inline-html)
45-45: Element: img
Inline HTML
(MD033, no-inline-html)
51-51: Element: a
Inline HTML
(MD033, no-inline-html)
51-51: Element: img
Inline HTML
(MD033, no-inline-html)
31-31: null
Bare URL used
(MD034, no-bare-urls)
1-1: null
First line in a file should be a top-level heading
(MD041, first-line-heading, first-line-h1)
45-45: null
Images should have alternate text (alt text)
(MD045, no-alt-text)
51-51: null
Images should have alternate text (alt text)
(MD045, no-alt-text)
🪛 Biome (1.9.4)
packages/platform/platform-fastify/src/services/PlatformFastifyResponse.ts
[error] 4-4: A Node.js builtin module should be imported with the node: protocol.
Using the node: protocol is more explicit and signals that the imported module belongs to Node.js.
Unsafe fix: Add the node: protocol.
(lint/style/useNodejsImportProtocol)
packages/platform/platform-fastify/src/components/PlatformFastify.ts
[error] 24-24: A Node.js builtin module should be imported with the node: protocol.
Using the node: protocol is more explicit and signals that the imported module belongs to Node.js.
Unsafe fix: Add the node: protocol.
(lint/style/useNodejsImportProtocol)
[error] 172-172: Forbidden non-null assertion.
(lint/style/noNonNullAssertion)
[error] 329-329: Reassigning a function parameter is confusing.
The parameter is declared here:
Use a local variable instead.
(lint/style/noParameterAssign)
🔇 Additional comments (41)
packages/platform/platform-fastify/tsconfig.esm.json (2)
1-2: LGTM! Proper base configuration.
The configuration correctly extends from @tsed/typescript/tsconfig.node.json, which provides the base TypeScript settings for Node.js projects.
3-11: LGTM! Well-structured compiler options.
The compiler options are properly configured for:
- ESM output structure (
lib/esmandlib/types) - Project references (composite project)
- Type declarations
- Module resolution
packages/platform/platform-fastify/tsconfig.spec.json (1)
9-30: Consider removing unused module path mappings
Several mapped modules appear to be unused in the test or source files. Consider cleaning up unused mappings to improve maintainability and compilation performance.
Let's verify the current module usage:
#!/bin/bash
# Description: Analyze module usage in test and source files
echo "Analyzing imports in test and source files..."
# Get all TypeScript files
fd -e ts -E "*.d.ts" . packages/platform/platform-fastify/src packages/platform/platform-fastify/test | while read -r file; do
echo "=== Analyzing $file ==="
# Extract all imports
ast-grep --pattern 'import { $$$ } from "$_"' "$file"
ast-grep --pattern 'import $_' "$file"
done
echo "Checking dynamic imports..."
rg "import\(" -t ts packages/platform/platform-fastify/src packages/platform/platform-fastify/testpackages/platform/platform-fastify/src/services/PlatformFastifyRequest.ts (1)
1-59: Code changes look good
The implementation of PlatformFastifyRequest aligns with the expected integration with Fastify. The methods correctly extend and customize the base PlatformRequest functionalities for the Fastify environment.
packages/platform/platform-fastify/src/services/PlatformFastifyResponse.ts (1)
4-4: 🧹 Nitpick (assertive)
Use 'node:' protocol when importing Node.js built-in modules
It's recommended to use the 'node:' protocol when importing Node.js built-in modules to explicitly indicate that the module is a built-in Node.js module.
Apply this diff to update the import statement:
-import type {ServerResponse} from "http";
+import type {ServerResponse} from "node:http";🧰 Tools
🪛 Biome (1.9.4)
[error] 4-4: A Node.js builtin module should be imported with the node: protocol.
Using the node: protocol is more explicit and signals that the imported module belongs to Node.js.
Unsafe fix: Add the node: protocol.
(lint/style/useNodejsImportProtocol)
packages/platform/platform-fastify/src/components/PlatformFastify.ts (2)
24-24: 🧹 Nitpick (assertive)
Use 'node:' protocol when importing Node.js built-in modules
It's recommended to use the 'node:' protocol when importing Node.js built-in modules to explicitly indicate that the module is a built-in Node.js module.
Apply this diff to update the import statement:
-import {IncomingMessage, ServerResponse} from "http";
+import {IncomingMessage, ServerResponse} from "node:http";🧰 Tools
🪛 Biome (1.9.4)
[error] 24-24: A Node.js builtin module should be imported with the node: protocol.
Using the node: protocol is more explicit and signals that the imported module belongs to Node.js.
Unsafe fix: Add the node: protocol.
(lint/style/useNodejsImportProtocol)
329-329: 🧹 Nitpick (assertive)
Avoid reassigning function parameters
Reassigning a function parameter can lead to confusion and potential bugs. Instead, assign the new value to a new variable to improve code clarity and maintainability.
Apply this diff to avoid reassigning the parameter:
-plugin = {env, use: plugin};
+const resolvedPlugin = {env, use: plugin};Ensure that subsequent references to plugin are updated to resolvedPlugin.
🧰 Tools
🪛 Biome (1.9.4)
[error] 329-329: Reassigning a function parameter is confusing.
The parameter is declared here:
Use a local variable instead.
(lint/style/noParameterAssign)
packages/platform/platform-fastify/test/app/public/index.html (1)
1-5: Enhance HTML structure with proper declarations
The HTML file is missing essential structural elements including DOCTYPE declaration, language attribute, head section, and meta tags.
packages/platform/platform-fastify/.npmignore (1)
1-7: Consider adding more common ignore patterns
The current patterns are good but could be enhanced with additional common patterns.
packages/platform/platform-fastify/src/exports.ts (1)
1-6: LGTM! Clean platform adapter setup
The code correctly sets up the Fastify platform adapter for both testing and building purposes. The implementation is clean and follows the expected pattern.
packages/platform/platform-fastify/src/index.ts (1)
1-9: LGTM! Verify all exported modules
The barrel exports are well-structured and include all necessary platform components. Let's verify that all exported modules exist.
✅ Verification successful
Let me verify the exports.js file which is also mentioned in the barrel file but wasn't included in our first search.
All exported modules verified successfully
All modules referenced in the barrel file exist in their expected locations:
- components/PlatformFastify.ts
- exports.ts
- interfaces/interfaces.ts
- interfaces/PlatformFastifySettings.ts
- services/PlatformFastifyRequest.ts
- services/PlatformFastifyResponse.ts
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify all exported modules exist
# Note: Using fd to find files as paths are relative to repo root
echo "Checking for exported modules..."
fd -e ts -e js "PlatformFastify.ts$|interfaces.ts$|PlatformFastifySettings.ts$|PlatformFastifyRequest.ts$|PlatformFastifyResponse.ts$" packages/platform/platform-fastify/src/
Length of output: 610
Script:
#!/bin/bash
# Check if exports.js/ts exists
fd -e ts -e js "^exports\." packages/platform/platform-fastify/src/
Length of output: 119
packages/platform/platform-fastify/src/interfaces/PlatformFastifySettings.ts (2)
1-1: Remove unused import comment
The commented import for Koa router options should be removed as it's not being used.
5-16: 🧹 Nitpick (assertive)
Add JSDoc documentation to enhance code clarity
The interface would benefit from proper documentation to explain its purpose and usage.
+/**
+ * Settings for the Fastify platform integration
+ * @interface PlatformFastifySettings
+ */
export interface PlatformFastifySettings {
+ /**
+ * Optional Fastify instance for custom configuration
+ * @type {FastifyInstance}
+ */
app?: FastifyInstance;
}Likely invalid or redundant comment.
packages/platform/platform-fastify/vitest.config.mts (2)
1-1:
Remove @ts-ignore and fix the type error properly.
Using @ts-ignore masks potential type issues. Please investigate and fix the underlying type error.
Let's check if there are other instances of @ts-ignore:
12-17: Verify the feasibility of high coverage thresholds.
The coverage thresholds are set quite high:
- Statements: 99.15%
- Branches: 95.6%
- Functions: 100%
- Lines: 99.15%
While high coverage is excellent for quality, let's verify if these thresholds align with the current test coverage.
✅ Verification successful
Since the previous attempt didn't find any coverage files, let's try a different approach to verify the test coverage. We'll check if there are any test files and their content to assess the feasibility of achieving such high coverage thresholds.
Based on the examination of the test files and source code, I can now provide a final response about the coverage thresholds:
The high coverage thresholds are feasible and justified
The codebase demonstrates comprehensive test coverage with:
- Extensive unit tests for core components (PlatformFastify, PlatformFastifyRequest, PlatformFastifyResponse)
- Thorough integration tests covering all major platform features
- Well-structured test cases that cover edge cases and error scenarios
- Small, focused codebase with clear responsibilities
The high thresholds are supported by:
- Complete test coverage of all public methods
- Extensive test scenarios in platform-fastify.spec.ts
- Proper mocking and isolation in unit tests
- Clear separation of concerns making the code highly testable
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check current test coverage in the platform-fastify package
fd "coverage-final.json" --exec cat {} | jq '.total'
Length of output: 52
Script:
#!/bin/bash
# Let's try running the tests to generate coverage
cd packages/platform/platform-fastify && npm run test:coverage
Length of output: 401
Script:
#!/bin/bash
# Find test files in the platform-fastify package
fd ".(test|spec).(ts|js|mts|mjs)" packages/platform/platform-fastify
# Count the number of source files to compare with test files
fd ".(ts|js|mts|mjs)$" packages/platform/platform-fastify --exclude ".(test|spec).(ts|js|mts|mjs)$"
Length of output: 1549
Script:
#!/bin/bash
# Let's examine the test files content to assess their coverage
for file in $(fd ".(test|spec).ts" packages/platform/platform-fastify); do
echo "=== $file ==="
cat "$file" | grep -E "describe|it\s*\(|test\s*\("
done
# Let's also check the source files to understand their complexity
for file in $(fd ".ts$" packages/platform/platform-fastify --exclude ".(test|spec).ts$" --exclude "interfaces"); do
echo "=== $file ==="
cat "$file"
done
Length of output: 31463
packages/platform/platform-fastify/test/app/Server.ts (1)
10-10: Consider making port configurable via environment variables
Hardcoding the port number limits flexibility across different environments.
packages/platform/platform-fastify/test/app/index.ts (2)
32-35: Remove redundant error logging.
The error is being logged twice using both console.error and $log.error.
14-18: 🛠️ Refactor suggestion
Add request parameter validation and error handling.
The route handler should validate the id parameter and return appropriate error responses. Consider using class-validator or a similar validation library.
@Get("/:id")
+ @Returns(400).Description("Invalid ID provided")
+ @Returns(200).Description("Success")
getById(@PathParams("id") id: string) {
+ if (!id?.trim()) {
+ throw new BadRequest("Invalid ID provided");
+ }
return {test: "Hello world", id};
}Likely invalid or redundant comment.
packages/platform/platform-fastify/src/components/PlatformFastify.spec.ts (3)
13-19: Enhance test coverage with additional test cases.
The current test only covers the basic happy path. Consider adding:
- Test with custom configuration options
- Error scenarios (e.g., invalid Server class)
- Edge cases with different platform settings
26-32: 🛠️ Refactor suggestion
Improve test description and add async error handling.
The test description "should create platform" is too generic and the async error handling could be improved.
- it("should create platform", async () => {
+ it("should bootstrap platform with default configuration", async () => {
try {
await PlatformFastify.bootstrap(Server, {});
expect(PlatformBuilder.bootstrap).toHaveBeenCalledWith(Server, {
adapter: PlatformFastify
});
+ } catch (error) {
+ fail("Bootstrap should not throw an error");
+ }
});Likely invalid or redundant comment.
5-5: 🧹 Nitpick (assertive)
Consider using a more realistic test class.
The Server class is empty and might not represent real-world scenarios accurately. Consider adding minimal required methods/properties to better test platform integration.
-class Server {}
+class Server {
+ // Minimum required setup for a Fastify server
+ configure() {}
+ $beforeRoutesInit() {}
+ $afterRoutesInit() {}
+}Likely invalid or redundant comment.
packages/platform/platform-fastify/src/services/PlatformFastifyRequest.spec.ts (4)
6-16: Extract test utility to a shared location.
The createRequest helper could be useful across multiple test files.
28-35: Enhance secure protocol testing.
The secure protocol test could be more comprehensive.
37-45: Add edge cases for host testing.
The host testing could be more robust.
47-54: Enhance getReq() test coverage.
The getReq() test could be more comprehensive.
packages/platform/platform-http/src/common/decorators/params/request.spec.ts (1)
1-1: LGTM! Using Node.js prefixed imports.
The change to use node:http instead of http follows Node.js best practices for built-in modules. This helps distinguish built-in modules from third-party ones and ensures consistent resolution.
packages/platform/platform-http/src/common/decorators/params/request.ts (1)
1-1: LGTM! Consistent with spec file changes.
The update to use node:http maintains consistency with the corresponding spec file and follows Node.js best practices.
packages/platform/platform-fastify/test/platform-fastify.spec.ts (3)
6-10: LGTM! Well-structured test initialization.
The test setup properly initializes the PlatformTestSdk with the necessary configuration for Fastify integration.
26-28: Document rationale for skipped tests
Several test suites are skipped with the comment "untestable with Fastify". Consider:
- Adding detailed comments explaining why these features are untestable
- Creating issues to track these limitations
- Documenting these limitations in the README
This will help maintainers understand the platform's limitations and potentially find solutions in future versions.
Would you like me to help create GitHub issues to track these limitations?
Also applies to: 85-96
12-99: LGTM! Comprehensive test coverage.
The test suite provides thorough coverage of the Fastify platform integration, including:
- Core functionality (handlers, controllers, responses)
- Parameter handling (headers, path, query, body)
- Session and cookie management
- Error handling and response filters
- Authentication and routing
packages/platform/platform-fastify/src/services/PlatformFastifyResponse.spec.ts (3)
5-19: Consider extracting test helper to a shared location
The createResponse helper function could be useful for other test files.
21-68: Add tests for error handling scenarios
The test suite should include additional scenarios for error handling.
78-113: Add security tests for URL handling
The location header tests should include security-related scenarios.
packages/platform/platform-fastify/package.json (3)
60-64: Pin dependency versions for better stability
Using >= for dependencies can lead to unexpected behavior.
81-95: Consider adding version upper bounds to peer dependencies
The current peer dependencies use >= which might lead to compatibility issues.
27-47: 🧹 Nitpick (assertive)
Clean up keywords and add missing metadata
- Remove duplicate typescript-related keywords
- Consider adding
enginesfield to specify Node.js version requirements
"keywords": [
"Koa",
"TypeScript",
- "typescript",
"Decorator",
// ...
],
+ "engines": {
+ "node": ">=16.0.0"
+ },Likely invalid or redundant comment.
packages/platform/platform-fastify/readme.md (2)
33-39: Enhance installation instructions
The installation section could be more comprehensive.
61-61: Update copyright year range
The copyright year range (2016 - 2018) appears outdated for this new package.
🧰 Tools
🪛 LanguageTool
[typographical] ~61-~61: If you want to indicate numerical ranges or time ranges, consider using an en dash.
Context: ...he MIT License (MIT) Copyright (c) 2016 - 2018 Romain Lenzotti Permission is here...
(DASH_RULE)
packages/platform/platform-router/src/domain/PlatformHandlerMetadata.ts (1)
142-144: LGTM: Well-implemented middleware type check
The implementation correctly combines injectability check with handler type verification to identify raw middleware handlers. The method follows the established patterns in the class and has a clear, single responsibility.
packages/platform/platform-router/src/domain/PlatformHandlerMetadata.spec.ts (1)
37-37: LGTM: Comprehensive test coverage for isRawMiddleware()
The tests thoroughly verify the behavior of isRawMiddleware() across all relevant scenarios:
- Context handlers (false)
- Raw functions (true)
- Raw error functions (true)
- Endpoint handlers (false)
- Middleware with injection (false)
Also applies to: 54-54, 72-72, 91-91, 124-124, 152-152
tsconfig.json (1)
101-103:
Remove duplicate platform-koa reference and add platform-fastify
This issue was previously identified. The platform-koa reference appears twice, and the platform-fastify reference is missing.
Apply these changes:
- {
- "path": "./packages/platform/platform-koa/tsconfig.json"
- },
+ {
+ "path": "./packages/platform/platform-fastify/tsconfig.json"
+ },| "exclude": [ | ||
| "node_modules", | ||
| "test", | ||
| "lib", | ||
| "benchmark", | ||
| "coverage", | ||
| "spec", | ||
| "**/*.benchmark.ts", | ||
| "**/*.spec.ts", | ||
| "keys", | ||
| "**/__mock__/**", | ||
| "webpack.config.js" | ||
| ] |
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Consider adding more common test and development file patterns.
The exclude patterns are good but could be more comprehensive. Consider adding these common patterns:
"exclude": [
"node_modules",
"test",
"lib",
"benchmark",
"coverage",
"spec",
"**/*.benchmark.ts",
"**/*.spec.ts",
+ "**/*.test.ts",
+ "**/__tests__/**",
+ "**/*.stories.ts",
+ "**/*.config.ts",
"keys",
"**/__mock__/**",
"webpack.config.js"
]📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| "exclude": [ | |
| "node_modules", | |
| "test", | |
| "lib", | |
| "benchmark", | |
| "coverage", | |
| "spec", | |
| "**/*.benchmark.ts", | |
| "**/*.spec.ts", | |
| "keys", | |
| "**/__mock__/**", | |
| "webpack.config.js" | |
| ] | |
| "exclude": [ | |
| "node_modules", | |
| "test", | |
| "lib", | |
| "benchmark", | |
| "coverage", | |
| "spec", | |
| "**/*.benchmark.ts", | |
| "**/*.spec.ts", | |
| "**/*.test.ts", | |
| "**/__tests__/**", | |
| "**/*.stories.ts", | |
| "**/*.config.ts", | |
| "keys", | |
| "**/__mock__/**", | |
| "webpack.config.js" | |
| ] |
| "types": ["vite/client", "vitest/globals"] | ||
| }, | ||
| "include": ["src/**/*.spec.ts", "test/**/*.spec.ts", "vitest.config.mts"], | ||
| "exclude": ["node_modules", "lib", "benchmark", "coverage"] |
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Consider expanding test file patterns
The current include patterns might miss some test-related files. Consider adding patterns for test helpers and utilities.
"types": ["vite/client", "vitest/globals"],
"include": [
"src/**/*.spec.ts",
"test/**/*.spec.ts",
+ "test/**/*.helper.ts",
+ "test/**/*.fixtures.ts",
+ "test/**/*.utils.ts",
"vitest.config.mts"
],📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| "types": ["vite/client", "vitest/globals"] | |
| }, | |
| "include": ["src/**/*.spec.ts", "test/**/*.spec.ts", "vitest.config.mts"], | |
| "exclude": ["node_modules", "lib", "benchmark", "coverage"] | |
| "types": ["vite/client", "vitest/globals"], | |
| "include": [ | |
| "src/**/*.spec.ts", | |
| "test/**/*.spec.ts", | |
| "test/**/*.helper.ts", | |
| "test/**/*.fixtures.ts", | |
| "test/**/*.utils.ts", | |
| "vitest.config.mts" | |
| ], | |
| "exclude": ["node_modules", "lib", "benchmark", "coverage"] |
| "baseUrl": ".", | ||
| "rootDir": "../..", |
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Consider using an absolute path for rootDir
The relative path "../.." in rootDir might cause issues if the project structure changes. Consider using an absolute path or a path relative to the project root to make the configuration more robust.
"compilerOptions": {
"baseUrl": ".",
- "rootDir": "../..",
+ "rootDir": "${workspaceRoot}",Committable suggestion skipped: line range outside the PR's diff.
|
|
||
| export * from "./PlatformFastifySettings.js"; | ||
|
|
||
| export type PlatformFastifyPluginTypes = ((opts?: any) => any) | /*Type<any> |*/ string; |
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Improve type safety by specifying concrete types
The use of any in the function signature reduces type safety. Consider specifying more precise types for opts and the return value to enhance code reliability and maintainability.
| use: PlatformFastifyPluginTypes; | ||
| options?: FastifyRegisterOptions<FastifyPluginOptions>; | ||
| }; | ||
| export type PlatformFastifyPluginSettings = PlatformFastifyPluginTypes | PlatformFastifyPluginLoadingOptions | any; |
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Avoid using any in union types
Including any in a union type negates the benefits of strong typing provided by the other types. It's advisable to remove any and define more specific types to improve type safety.
| "references": [ | ||
| { | ||
| "path": "../../third-parties/components-scan/tsconfig.json" | ||
| }, | ||
| { | ||
| "path": "../../engines/tsconfig.json" | ||
| }, | ||
| { | ||
| "path": "../../core/tsconfig.json" | ||
| }, | ||
| { | ||
| "path": "../../di/tsconfig.json" | ||
| }, | ||
| { | ||
| "path": "../../specs/exceptions/tsconfig.json" | ||
| }, | ||
| { | ||
| "path": "../../specs/json-mapper/tsconfig.json" | ||
| }, | ||
| { | ||
| "path": "../platform-exceptions/tsconfig.json" | ||
| }, | ||
| { | ||
| "path": "../platform-log-middleware/tsconfig.json" | ||
| }, | ||
| { | ||
| "path": "../platform-middlewares/tsconfig.json" | ||
| }, | ||
| { | ||
| "path": "../platform-params/tsconfig.json" | ||
| }, | ||
| { | ||
| "path": "../platform-response-filter/tsconfig.json" | ||
| }, | ||
| { | ||
| "path": "../platform-router/tsconfig.json" | ||
| }, | ||
| { | ||
| "path": "../platform-views/tsconfig.json" | ||
| }, | ||
| { | ||
| "path": "../../specs/schema/tsconfig.json" | ||
| }, | ||
| { | ||
| "path": "./tsconfig.esm.json" | ||
| }, | ||
| { | ||
| "path": "./tsconfig.spec.json" | ||
| } | ||
| ] |
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Consider optimizing project references.
The large number of project references might impact build time. Consider:
- Grouping related references into workspace projects
- Using path aliases for frequently referenced modules
| "baseUrl": ".", | ||
| "noEmit": true | ||
| }, | ||
| "include": [], |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Specify source files in the include array.
An empty include array might unintentionally exclude source files. Consider adding source paths:
- "include": [],
+ "include": ["src/**/*.ts", "test/**/*.ts"],Committable suggestion skipped: line range outside the PR's diff.
| describe("PlatformFastifyRequest", () => { | ||
| beforeEach(() => PlatformTest.create()); | ||
| afterEach(() => PlatformTest.reset()); | ||
|
|
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Consider using more specific test lifecycle hooks.
The current setup/teardown is very broad. Consider using more specific hooks:
- beforeEach(() => PlatformTest.create());
- afterEach(() => PlatformTest.reset());
+ beforeEach(async () => {
+ await PlatformTest.create({
+ platform: PlatformFastifyRequest
+ });
+ });
+ afterEach(async () => {
+ await PlatformTest.reset();
+ jest.clearAllMocks();
+ });📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| describe("PlatformFastifyRequest", () => { | |
| beforeEach(() => PlatformTest.create()); | |
| afterEach(() => PlatformTest.reset()); | |
| describe("PlatformFastifyRequest", () => { | |
| beforeEach(async () => { | |
| await PlatformTest.create({ | |
| platform: PlatformFastifyRequest | |
| }); | |
| }); | |
| afterEach(async () => { | |
| await PlatformTest.reset(); | |
| jest.clearAllMocks(); | |
| }); | |
| describe("stream()", () => { | ||
| it("should set body", () => { | ||
| const {res, response} = createResponse(); | ||
|
|
||
| response.stream("body"); | ||
|
|
||
| expect(res.data).toEqual("body"); | ||
| }); | ||
| }); |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Add stream-specific error scenarios
The stream test cases should include:
- Error handling for stream failures
- Memory constraints scenarios
- Invalid stream input cases
Example test case:
it("should handle stream errors", async () => {
const { response } = createResponse();
const errorStream = new Readable({
read() {
this.emit('error', new Error('Stream failed'));
}
});
await expect(response.stream(errorStream)).rejects.toThrow('Stream failed');
});| A package of Ts.ED framework. See website: https://tsed.io/getting-started/ | ||
|
|
There was a problem hiding this comment.
🛠️ Refactor suggestion
Add configuration examples section
Add a new section with:
- Basic configuration example
- Common use cases
- Integration with existing Ts.ED applications
Example content to add:
## Configuration
```typescript
import {Configuration} from "@tsed/common";
import "@tsed/platform-fastify"; // import fastify platform
@Configuration({
platform: "fastify",
fastify: {
// your fastify options
}
})
export class Server {
}🧰 Tools
🪛 Markdownlint (0.35.0)
31-31: null
Bare URL used
(MD034, no-bare-urls)
Romakita
force-pushed
the
production
branch
2 times, most recently
from
de8df3b to
474e2d8
Compare
Romakita
force-pushed
the
feat-fastify-v8
branch
from
786b751 to
7d4c97e
Compare
Romakita
force-pushed
the
feat-fastify-v8
branch
from
7d4c97e to
ab0d429
Compare
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
| await request | ||
| .get("/rest/auth/userinfo") | ||
| .set({ | ||
| Authorization: "wrong" |
Check failure
Code scanning / CodeQL
Hard-coded credentials Critical test
There was a problem hiding this comment.
Actionable comments posted: 20
🔭 Outside diff range comments (1)
packages/platform/platform-test-sdk/src/tests/testSession.ts (1)
Line range hint
42-57: Add Fastify platform support in logout method.The logout method currently handles 'koa' and 'express' platforms but lacks support for the new Fastify platform. This could lead to session cleanup issues when testing Fastify integration.
@Get("/logout") @Returns(204) logout(@Req() req: any) { switch (this.platformName) { case "koa": return Promise.resolve((req.ctx.session = null)); case "express": delete req.session.user; return promisify(req.session.destroy.bind(req.session))(); + case "fastify": + return new Promise<void>((resolve) => { + req.session.destroy((err: Error) => { + if (err) { + console.error("Error destroying fastify session:", err); + } + resolve(); + }); + }); } return Promise.resolve(); }
♻️ Duplicate comments (8)
packages/platform/platform-fastify/tsconfig.json (1)
7-7: 🛠️ Refactor suggestionSpecify source files in the include array.
An empty include array might unintentionally exclude source files. Consider adding source paths:
- "include": [], + "include": ["src/**/*.ts", "test/**/*.ts"],🧰 Tools
🪛 GitHub Actions: Build & Release
[warning] Warning: Statics middleware is not implemented yet
packages/platform/platform-fastify/test/app/views/view.ejs (1)
1-1:⚠️ Potential issueAdd fallback values and XSS protection.
The template needs improvements for security and robustness:
- Add fallback values for undefined variables
- Implement XSS protection using EJS's escape syntax
-<p>Hello <%= world %> with <%= opts %> and ID <%= localID %></p> +<p>Hello <%- world || 'Guest' %> with <%- opts || 'default' %> and ID <%- localID || 'N/A' %></p>🧰 Tools
🪛 GitHub Actions: Build & Release
[warning] Warning: Statics middleware is not implemented yet
packages/platform/platform-fastify/src/services/PlatformFastifyResponse.spec.ts (2)
5-19: 🧹 Nitpick (assertive)Extract and enhance the test helper function.
The
createResponsehelper function could be more reusable and maintainable.Consider:
- Moving it to a shared test utilities file
- Adding JSDoc documentation
- Making it more configurable for different test scenarios
/** * Creates a mock Fastify response object for testing * @param {Object} options - Configuration options * @param {Object} options.headers - Initial headers * @param {number} options.statusCode - Initial status code * @returns {Object} Mock response object and context */ export function createResponse(options = {}) { const response = PlatformTest.createResponse(); response.code = response.status; response.type = response.contentType; response.header = response.set; const ctx = PlatformTest.createRequestContext({ event: { response }, ResponseKlass: PlatformFastifyResponse, ...options }); return {res: response, response: ctx.response}; }🧰 Tools
🪛 GitHub Actions: Build & Release
[warning] Warning: Statics middleware is not implemented yet
21-114: 🛠️ Refactor suggestionAdd missing test scenarios for comprehensive coverage.
The test suite should include additional test cases for better coverage.
Add tests for:
- Error handling when setting invalid status codes
- Edge cases for content-type headers
- Error cases for stream operations
- Header validation scenarios
- Security-related URL handling in location tests
Example test cases:
it("should throw error for invalid status code", () => { const {response} = createResponse(); expect(() => response.status(1000)).toThrow(); }); it("should handle stream errors", async () => { const {response} = createResponse(); const errorStream = new Readable({ read() { this.emit('error', new Error('Stream failed')); } }); await expect(response.stream(errorStream)).rejects.toThrow('Stream failed'); }); it("should sanitize location URL", () => { const {res, response} = createResponse(); response.location("javascript:alert(1)"); expect(res.headers.location).toEqual("/"); });🧰 Tools
🪛 GitHub Actions: Build & Release
[warning] Warning: Statics middleware is not implemented yet
packages/platform/platform-fastify/package.json (2)
60-64: 🛠️ Refactor suggestionPin dependency versions for better stability.
Using
>=for dependencies can lead to unexpected behavior.Apply this diff:
"dependencies": { - "@fastify/middie": ">=9.0.2", + "@fastify/middie": "^9.0.2", - "content-disposition": ">=0.5.4", + "content-disposition": "^0.5.4", "tslib": "2.6.1" }🧰 Tools
🪛 GitHub Actions: Build & Release
[warning] Warning: Statics middleware is not implemented yet
81-94: 🧹 Nitpick (assertive)Consider adding version upper bounds to peer dependencies.
Using
>=without upper bounds in peer dependencies might lead to compatibility issues.Apply version ranges with upper bounds:
"peerDependencies": { - "@fastify/accepts": ">=4.3.0", + "@fastify/accepts": "^4.3.0 || ^5.0.0", - "@fastify/cookie": ">=9.3.1", + "@fastify/cookie": "^9.3.1 || ^10.0.0", // Apply similar pattern to other dependencies }🧰 Tools
🪛 GitHub Actions: Build & Release
[warning] Warning: Statics middleware is not implemented yet
packages/platform/platform-fastify/readme.md (2)
33-39: 🧹 Nitpick (assertive)Enhance installation instructions.
The installation section could be more comprehensive.
Add:
- Optional dependencies installation
- Basic configuration example
- Common usage patterns
🧰 Tools
🪛 GitHub Actions: Build & Release
[warning] Warning: Statics middleware is not implemented yet
61-61: 🛠️ Refactor suggestionUpdate copyright year range.
The copyright year range is outdated for this new package.
- Copyright (c) 2016 - 2018 Romain Lenzotti + Copyright (c) 2016 – 2024 Romain Lenzotti🧰 Tools
🪛 LanguageTool
[typographical] ~61-~61: If you want to indicate numerical ranges or time ranges, consider using an en dash.
Context: ...he MIT License (MIT) Copyright (c) 2016 - 2018 Romain Lenzotti Permission is here...(DASH_RULE)
🪛 GitHub Actions: Build & Release
[warning] Warning: Statics middleware is not implemented yet
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (32)
packages/platform/platform-fastify/.npmignore(1 hunks)packages/platform/platform-fastify/.swcrc(1 hunks)packages/platform/platform-fastify/package.json(1 hunks)packages/platform/platform-fastify/readme.md(1 hunks)packages/platform/platform-fastify/src/components/PlatformFastify.spec.ts(1 hunks)packages/platform/platform-fastify/src/components/PlatformFastify.ts(1 hunks)packages/platform/platform-fastify/src/index.ts(1 hunks)packages/platform/platform-fastify/src/interfaces/PlatformFastifySettings.ts(1 hunks)packages/platform/platform-fastify/src/interfaces/interfaces.ts(1 hunks)packages/platform/platform-fastify/src/services/PlatformFastifyRequest.spec.ts(1 hunks)packages/platform/platform-fastify/src/services/PlatformFastifyRequest.ts(1 hunks)packages/platform/platform-fastify/src/services/PlatformFastifyResponse.spec.ts(1 hunks)packages/platform/platform-fastify/src/services/PlatformFastifyResponse.ts(1 hunks)packages/platform/platform-fastify/test/app/Server.ts(1 hunks)packages/platform/platform-fastify/test/app/index.ts(1 hunks)packages/platform/platform-fastify/test/app/public/index.html(1 hunks)packages/platform/platform-fastify/test/app/views/view.ejs(1 hunks)packages/platform/platform-fastify/test/health.spec.ts(1 hunks)packages/platform/platform-fastify/test/platform-fastify.spec.ts(1 hunks)packages/platform/platform-fastify/test/test-auth.integration.spec.ts(1 hunks)packages/platform/platform-fastify/test/test-session.integration.spec.ts(1 hunks)packages/platform/platform-fastify/tsconfig.esm.json(1 hunks)packages/platform/platform-fastify/tsconfig.json(1 hunks)packages/platform/platform-fastify/tsconfig.spec.json(1 hunks)packages/platform/platform-fastify/vitest.config.mts(1 hunks)packages/platform/platform-http/src/common/services/PlatformHandler.ts(1 hunks)packages/platform/platform-response-filter/src/services/PlatformContentTypeResolver.spec.ts(3 hunks)packages/platform/platform-response-filter/src/services/PlatformContentTypeResolver.ts(1 hunks)packages/platform/platform-response-filter/src/services/__mock__/response.txt(1 hunks)packages/platform/platform-router/src/domain/PlatformHandlerMetadata.spec.ts(6 hunks)packages/platform/platform-router/src/domain/PlatformHandlerMetadata.ts(1 hunks)packages/platform/platform-test-sdk/src/tests/testSession.ts(1 hunks)
🧰 Additional context used
📓 Learnings (2)
packages/platform/platform-fastify/tsconfig.esm.json (1)
Learnt from: Romakita
PR: tsedio/tsed#2925
File: packages/platform/platform-fastify/tsconfig.esm.json:3-11
Timestamp: 2024-12-10T17:46:27.733Z
Learning: Dans le projet Ts.ED, lorsqu'un fichier `tsconfig` comme `packages/platform/platform-fastify/tsconfig.esm.json` étend `"@tsed/typescript/tsconfig.node.json"`, il n'est pas nécessaire de répéter les options du compilateur telles que `"moduleResolution": "node"` et `"sourceMap": true`, car elles sont déjà incluses dans le fichier de configuration étendu.
packages/platform/platform-fastify/tsconfig.json (1)
Learnt from: Romakita
PR: tsedio/tsed#2925
File: packages/platform/platform-fastify/tsconfig.esm.json:3-11
Timestamp: 2024-12-10T17:46:27.733Z
Learning: Dans le projet Ts.ED, lorsqu'un fichier `tsconfig` comme `packages/platform/platform-fastify/tsconfig.esm.json` étend `"@tsed/typescript/tsconfig.node.json"`, il n'est pas nécessaire de répéter les options du compilateur telles que `"moduleResolution": "node"` et `"sourceMap": true`, car elles sont déjà incluses dans le fichier de configuration étendu.
🪛 GitHub Actions: Build & Release
packages/platform/platform-fastify/test/app/public/index.html
[warning] Warning: Statics middleware is not implemented yet
packages/platform/platform-fastify/test/app/views/view.ejs
[warning] Warning: Statics middleware is not implemented yet
packages/platform/platform-fastify/.npmignore
[warning] Warning: Statics middleware is not implemented yet
packages/platform/platform-fastify/src/interfaces/PlatformFastifySettings.ts
[warning] Warning: Statics middleware is not implemented yet
packages/platform/platform-fastify/vitest.config.mts
[warning] Warning: Statics middleware is not implemented yet
packages/platform/platform-fastify/readme.md
[warning] Warning: Statics middleware is not implemented yet
packages/platform/platform-fastify/test/health.spec.ts
[warning] Warning: Statics middleware is not implemented yet
packages/platform/platform-fastify/tsconfig.spec.json
[warning] Warning: Statics middleware is not implemented yet
packages/platform/platform-fastify/tsconfig.esm.json
[warning] Warning: Statics middleware is not implemented yet
packages/platform/platform-fastify/test/app/Server.ts
[warning] Warning: Statics middleware is not implemented yet
packages/platform/platform-fastify/src/services/PlatformFastifyResponse.spec.ts
[warning] Warning: Statics middleware is not implemented yet
packages/platform/platform-fastify/src/components/PlatformFastify.spec.ts
[warning] Warning: Statics middleware is not implemented yet
packages/platform/platform-fastify/src/index.ts
[warning] Warning: Statics middleware is not implemented yet
packages/platform/platform-fastify/test/platform-fastify.spec.ts
[error] 103-103: Test failure: Session test failed - expected user object to deeply equal {email: '[email protected]', name: 'name'} but received additional 'password' field
[error] 185-185: Test failure: Auth test failed - expected HTTP 200 OK for /doc/swagger.json endpoint but got 404 Not Found
[warning] Warning: Statics middleware is not implemented yet
packages/platform/platform-fastify/src/services/PlatformFastifyRequest.ts
[warning] Warning: Statics middleware is not implemented yet
packages/platform/platform-fastify/package.json
[warning] Warning: Statics middleware is not implemented yet
packages/platform/platform-fastify/test/app/index.ts
[warning] Warning: Statics middleware is not implemented yet
packages/platform/platform-fastify/src/interfaces/interfaces.ts
[warning] Warning: Statics middleware is not implemented yet
packages/platform/platform-fastify/test/test-session.integration.spec.ts
[error] 108-108: Test failure: Session test failed - expected user object to deeply equal {email: '[email protected]', name: 'name'} but received additional 'password' field
[warning] Warning: Statics middleware is not implemented yet
packages/platform/platform-fastify/src/services/PlatformFastifyResponse.ts
[warning] Warning: Statics middleware is not implemented yet
packages/platform/platform-fastify/tsconfig.json
[warning] Warning: Statics middleware is not implemented yet
packages/platform/platform-fastify/src/services/PlatformFastifyRequest.spec.ts
[warning] Warning: Statics middleware is not implemented yet
packages/platform/platform-fastify/.swcrc
[warning] Warning: Statics middleware is not implemented yet
packages/platform/platform-fastify/test/test-auth.integration.spec.ts
[error] Failed to load url ../data/swagger.json - file not found
[warning] Warning: Statics middleware is not implemented yet
packages/platform/platform-fastify/src/components/PlatformFastify.ts
[warning] Warning: Statics middleware is not implemented yet
🪛 LanguageTool
packages/platform/platform-fastify/readme.md
[style] ~49-~49: Using many exclamation marks might seem excessive (in this case: 7 exclamation marks for a text that’s 2441 characters long)
Context: ...## Backers Thank you to all our backers! 🙏 [[Become a backer](https://opencolle...
(EN_EXCESSIVE_EXCLAMATION)
[typographical] ~61-~61: If you want to indicate numerical ranges or time ranges, consider using an en dash.
Context: ...he MIT License (MIT) Copyright (c) 2016 - 2018 Romain Lenzotti Permission is here...
(DASH_RULE)
🪛 markdownlint-cli2 (0.17.2)
packages/platform/platform-fastify/readme.md
1-1: Inline HTML
Element: p
(MD033, no-inline-html)
1-1: First line in a file should be a top-level heading
null
(MD041, first-line-heading, first-line-h1)
2-2: Inline HTML
Element: a
(MD033, no-inline-html)
2-2: Inline HTML
Element: img
(MD033, no-inline-html)
5-5: Inline HTML
Element: div
(MD033, no-inline-html)
6-6: Inline HTML
Element: h1
(MD033, no-inline-html)
19-19: Inline HTML
Element: div
(MD033, no-inline-html)
20-20: Inline HTML
Element: a
(MD033, no-inline-html)
21-21: Inline HTML
Element: span
(MD033, no-inline-html)
22-22: Inline HTML
Element: a
(MD033, no-inline-html)
23-23: Inline HTML
Element: span
(MD033, no-inline-html)
24-24: Inline HTML
Element: a
(MD033, no-inline-html)
25-25: Inline HTML
Element: span
(MD033, no-inline-html)
26-26: Inline HTML
Element: a
(MD033, no-inline-html)
29-29: Inline HTML
Element: hr
(MD033, no-inline-html)
31-31: Bare URL used
null
(MD034, no-bare-urls)
45-45: Inline HTML
Element: a
(MD033, no-inline-html)
45-45: Inline HTML
Element: img
(MD033, no-inline-html)
45-45: Images should have alternate text (alt text)
null
(MD045, no-alt-text)
51-51: Inline HTML
Element: a
(MD033, no-inline-html)
51-51: Inline HTML
Element: img
(MD033, no-inline-html)
51-51: Images should have alternate text (alt text)
null
(MD045, no-alt-text)
🪛 Biome (1.9.4)
packages/platform/platform-response-filter/src/services/PlatformContentTypeResolver.spec.ts
[error] 3-3: A Node.js builtin module should be imported with the node: protocol.
Using the node: protocol is more explicit and signals that the imported module belongs to Node.js.
Unsafe fix: Add the node: protocol.
(lint/style/useNodejsImportProtocol)
packages/platform/platform-fastify/test/test-session.integration.spec.ts
[error] 9-9: A Node.js builtin module should be imported with the node: protocol.
Using the node: protocol is more explicit and signals that the imported module belongs to Node.js.
Unsafe fix: Add the node: protocol.
(lint/style/useNodejsImportProtocol)
[error] 63-63: The assignment should not be in an expression.
The use of assignments in expressions is confusing.
Expressions are often considered as side-effect free.
(lint/suspicious/noAssignInExpressions)
[error] 66-66: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 14-28: Do not export from a test file.
(lint/suspicious/noExportsInTest)
[error] 29-33: Do not export from a test file.
(lint/suspicious/noExportsInTest)
[error] 34-73: Do not export from a test file.
(lint/suspicious/noExportsInTest)
packages/platform/platform-fastify/test/test-auth.integration.spec.ts
[error] 17-17: This type annotation is trivially inferred from its initialization.
Safe fix: Remove the type annotation.
(lint/style/noInferrableTypes)
[error] 61-61: Don't use 'Function' as a type.
Prefer explicitly define the function shape. This type accepts any function-like value, which can be a common source of bugs.
(lint/complexity/noBannedTypes)
packages/platform/platform-fastify/src/components/PlatformFastify.ts
[error] 25-25: A Node.js builtin module should be imported with the node: protocol.
Using the node: protocol is more explicit and signals that the imported module belongs to Node.js.
Unsafe fix: Add the node: protocol.
(lint/style/useNodejsImportProtocol)
[error] 176-176: Forbidden non-null assertion.
(lint/style/noNonNullAssertion)
[error] 333-333: Reassigning a function parameter is confusing.
The parameter is declared here:
Use a local variable instead.
(lint/style/noParameterAssign)
🪛 GitHub Check: CodeQL
packages/platform/platform-fastify/test/test-auth.integration.spec.ts
[failure] 137-137: Hard-coded credentials
The hard-coded value "wrong" is used as authorization header.
🔇 Additional comments (65)
packages/platform/platform-fastify/tsconfig.esm.json (4)
1-2: LGTM! Good choice of base configuration.Extending from
@tsed/typescript/tsconfig.node.jsonprovides a solid foundation with pre-configured compiler options for Node.js TypeScript projects.🧰 Tools
🪛 GitHub Actions: Build & Release
[warning] Warning: Statics middleware is not implemented yet
3-11: LGTM! Well-structured compiler options.The configuration correctly sets up:
- ESM output structure with appropriate directories
- TypeScript declaration file generation
- Project references support via
composite🧰 Tools
🪛 GitHub Actions: Build & Release
[warning] Warning: Statics middleware is not implemented yet
12-12: LGTM! Appropriate include patterns.The include patterns correctly target all TypeScript and JSON files in the source directory.
🧰 Tools
🪛 GitHub Actions: Build & Release
[warning] Warning: Statics middleware is not implemented yet
13-25: Consider adding more common test and development file patterns.The exclude patterns are good but could be more comprehensive. Consider adding these common patterns:
"exclude": [ "node_modules", "test", "lib", "benchmark", "coverage", "spec", "**/*.benchmark.ts", "**/*.spec.ts", + "**/*.test.ts", + "**/__tests__/**", + "**/*.stories.ts", + "**/*.config.ts", "keys", "**/__mock__/**", "webpack.config.js" ]🧰 Tools
🪛 GitHub Actions: Build & Release
[warning] Warning: Statics middleware is not implemented yet
packages/platform/platform-fastify/tsconfig.json (3)
1-2: LGTM! Base configuration is properly set up.The configuration correctly extends from the base TypeScript configuration.
🧰 Tools
🪛 GitHub Actions: Build & Release
[warning] Warning: Statics middleware is not implemented yet
3-6: LGTM! Compiler options are minimal and well-structured.The configuration avoids duplicating options from the base config and only includes necessary overrides.
🧰 Tools
🪛 GitHub Actions: Build & Release
[warning] Warning: Statics middleware is not implemented yet
8-39: LGTM! Project references are well-structured and necessary.The references are properly organized and each serves a specific purpose:
- Core framework components
- Platform integrations
- Specification and schema support
- Testing utilities
- Build configurations
Note: The warning about unimplemented statics middleware in the pipeline is expected for a new platform package and should be addressed in subsequent PRs.
🧰 Tools
🪛 GitHub Actions: Build & Release
[warning] Warning: Statics middleware is not implemented yet
packages/platform/platform-fastify/tsconfig.spec.json (6)
4-5: Consider using an absolute path for rootDirThe relative path
"../.."inrootDirmight cause issues if the project structure changes. Consider using an absolute path or a path relative to the project root to make the configuration more robust.🧰 Tools
🪛 GitHub Actions: Build & Release
[warning] Warning: Statics middleware is not implemented yet
9-30: Consider removing unused module path mappingsSeveral mapped modules in
tsconfig.spec.jsonare not being used in the test or source files.🧰 Tools
🪛 GitHub Actions: Build & Release
[warning] Warning: Statics middleware is not implemented yet
16-19: Address the statics middleware implementation warningThe pipeline warning indicates that the statics middleware is not implemented yet. Consider either:
- Implementing the statics middleware
- Removing the related path mappings if they won't be used
- Adding a TODO comment with a timeline for implementation
This will help resolve the pipeline warning:
Warning: Statics middleware is not implemented yet🧰 Tools
🪛 GitHub Actions: Build & Release
[warning] Warning: Statics middleware is not implemented yet
31-33: Consider expanding test file patternsThe current include patterns might miss some test-related files. Consider adding patterns for test helpers and utilities.
🧰 Tools
🪛 GitHub Actions: Build & Release
[warning] Warning: Statics middleware is not implemented yet
34-34: LGTM! Appropriate exclude patternsThe exclude patterns follow standard practices by ignoring build outputs, dependencies, and test coverage directories.
🧰 Tools
🪛 GitHub Actions: Build & Release
[warning] Warning: Statics middleware is not implemented yet
1-35: Add documentation for test configurationConsider adding a comment block at the top of the file explaining:
- The purpose of this test-specific configuration
- Why certain modules are mapped
- The relationship with Vite/Vitest setup
🧰 Tools
🪛 GitHub Actions: Build & Release
[warning] Warning: Statics middleware is not implemented yet
packages/platform/platform-response-filter/src/services/PlatformContentTypeResolver.ts (3)
1-1: Great improvement in type safety!The change from
anytounknowntype for thedataparameter enhances type safety by requiring explicit type checks before using the data.Also applies to: 9-13
14-18: Clean destructuring pattern!The destructuring pattern has been improved to directly extract
operationfromendpoint, making the code more concise.
23-23: Robust content type resolution logic!The improved logic:
- Handles application/json content type more precisely
- Properly handles edge cases with streams and buffers
- Maintains clear and concise conditional checks
Also applies to: 30-30
packages/platform/platform-response-filter/src/services/PlatformContentTypeResolver.spec.ts (2)
Line range hint
34-47: Good test coverage for Buffer handling!The test case properly validates that Buffer inputs are handled correctly by returning undefined content type.
48-77: Excellent test coverage for streams and objects!The new test cases:
- Validate stream handling returns undefined
- Confirm objects default to application/json when no specific content type is resolved
- Provide comprehensive coverage of the content type resolution logic
packages/platform/platform-test-sdk/src/tests/testSession.ts (1)
Line range hint
89-117: Verify test coverage for Fastify platform.The existing test scenario covers the basic session operations. However, ensure that it's executed against all supported platforms including Fastify to validate the session management implementation.
Run the following script to check test coverage for different platforms:
✅ Verification successful
Test coverage for session management is properly implemented for Fastify platform
The test scenario is already part of the Fastify platform's dedicated test suite (
packages/platform/platform-fastify/test/test-session.integration.spec.ts) and covers all essential session operations including connection, data retrieval, and session destruction.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for platform-specific test configurations rg -g '*.spec.ts' -g '*.test.ts' "PlatformTest.bootstrap.*server.*platform.*fastify" . # Check if there are dedicated Fastify platform tests fd -g '*fastify*.spec.ts' -g '*fastify*.test.ts'Length of output: 244
Script:
#!/bin/bash # Search for platform test initialization patterns rg "PlatformTest\.bootstrap" -g "*.spec.ts" -g "*.test.ts" -A 3 # Search for session management tests rg "describe.*session" -g "*.spec.ts" -g "*.test.ts" # Find platform-specific test files fd . -e spec.ts -e test.tsLength of output: 58379
packages/platform/platform-fastify/test/app/views/view.ejs (1)
1-1: Verify template serving functionality.The pipeline warning "Statics middleware is not implemented yet" might affect how templates are served in the Fastify platform. Ensure that template rendering is properly tested and working as expected.
🧰 Tools
🪛 GitHub Actions: Build & Release
[warning] Warning: Statics middleware is not implemented yet
packages/platform/platform-fastify/vitest.config.mts (2)
12-17: Consider more realistic coverage thresholds for a new package.The current thresholds (99.15% statements/lines, 100% functions) are exceptionally high and might be challenging to maintain as the codebase grows. While high coverage is excellent, such strict thresholds could:
- Lead to brittle tests
- Increase maintenance overhead
- Cause false positives
Consider starting with slightly lower thresholds (e.g., 90%) and gradually increasing them as the implementation matures.
🧰 Tools
🪛 GitHub Actions: Build & Release
[warning] Warning: Statics middleware is not implemented yet
5-21: 🧹 Nitpick (assertive)Address the Static middleware implementation warning.
The pipeline shows a warning about incomplete Static middleware implementation. This should be addressed before finalizing the PR.
Would you like me to help create an issue to track the Static middleware implementation? This would help ensure this doesn't get overlooked after the PR is merged.
🧰 Tools
🪛 GitHub Actions: Build & Release
[warning] Warning: Statics middleware is not implemented yet
packages/platform/platform-fastify/test/app/Server.ts (3)
12-12: Make the port configurable via environment variables
This suggestion has been raised before. Using a hardcoded port limits flexibility.🧰 Tools
🪛 GitHub Actions: Build & Release
[warning] Warning: Statics middleware is not implemented yet
13-15: Verify statics middleware usage
The pipeline warns that statics middleware is not implemented yet. Make sure the static file serving logic is fully supported before relying on it in production.🧰 Tools
🪛 GitHub Actions: Build & Release
[warning] Warning: Statics middleware is not implemented yet
25-44: Specify plugin versions and document plugin configurations
This suggestion has been raised before. Pinning plugin versions helps ensure consistent behavior across environments. Document the need forfastify-raw-bodyto avoid confusion.🧰 Tools
🪛 GitHub Actions: Build & Release
[warning] Warning: Statics middleware is not implemented yet
packages/platform/platform-fastify/src/services/PlatformFastifyRequest.ts (2)
46-48: Validate multi-value headers
this.raw.raw.headers[name.toLowerCase()]only returns a single string value. If multi-value headers are expected, confirm they are handled as needed.🧰 Tools
🪛 GitHub Actions: Build & Release
[warning] Warning: Statics middleware is not implemented yet
50-52: The getReq() method looks good
Returning the underlying Node.js request object provides flexibility for lower-level operations.🧰 Tools
🪛 GitHub Actions: Build & Release
[warning] Warning: Statics middleware is not implemented yet
packages/platform/platform-fastify/src/services/PlatformFastifyResponse.ts (9)
19-23: Use of.localsis approved
Initializingthis.raw.localsin the constructor provides an effective storage mechanism for request-specific data.🧰 Tools
🪛 GitHub Actions: Build & Release
[warning] Warning: Statics middleware is not implemented yet
32-34: getRes() method is solid
Exposing the underlying Node.js response object is helpful for specialized operations not covered by the Fastify interface.🧰 Tools
🪛 GitHub Actions: Build & Release
[warning] Warning: Statics middleware is not implemented yet
41-45: Status method implementation looks good
Usingthis.raw.code(status)aligns with Fastify conventions for setting HTTP status codes.🧰 Tools
🪛 GitHub Actions: Build & Release
[warning] Warning: Statics middleware is not implemented yet
59-63: contentType method usage is appropriate
Relying onthis.raw.type(contentType)properly sets the Content-Type header.🧰 Tools
🪛 GitHub Actions: Build & Release
[warning] Warning: Statics middleware is not implemented yet
74-76: Confirm correct handling of case-sensitivity for response headers
this.raw.getHeader(name)is case-insensitive by default. Verify that the name argument meets your standard conventions.🧰 Tools
🪛 GitHub Actions: Build & Release
[warning] Warning: Statics middleware is not implemented yet
78-81: attachment() method is correct
It properly sets theContent-Dispositionheader to handle file downloads.🧰 Tools
🪛 GitHub Actions: Build & Release
[warning] Warning: Statics middleware is not implemented yet
83-87: setHeader usage is consistent
Forwarding final header values tothis.raw.header(), withformatHeader(), maintains consistent formatting.🧰 Tools
🪛 GitHub Actions: Build & Release
[warning] Warning: Statics middleware is not implemented yet
89-93: stream() method logic is straightforward
Sending the data throughthis.raw.send(data)is sufficient for streaming scenarios.🧰 Tools
🪛 GitHub Actions: Build & Release
[warning] Warning: Statics middleware is not implemented yet
95-99: json() method usage aligns with Fastify
Callingthis.raw.send(data)with a JSON object is a reliable approach for sending JSON responses.🧰 Tools
🪛 GitHub Actions: Build & Release
[warning] Warning: Statics middleware is not implemented yet
packages/platform/platform-fastify/test/test-auth.integration.spec.ts (2)
61-61: Specify a more precise return type overFunction
UsingFunctionis too broad and undermines type safety. Consider specifying the function signature or using an arrow function type.-export function OAuth(options: any = {}): Function { +export function OAuth(options: any = {}): (...args: any[]) => any {🧰 Tools
🪛 Biome (1.9.4)
[error] 61-61: Don't use 'Function' as a type.
Prefer explicitly define the function shape. This type accepts any function-like value, which can be a common source of bugs.
(lint/complexity/noBannedTypes)
🪛 GitHub Actions: Build & Release
[error] Failed to load url ../data/swagger.json - file not found
[warning] Warning: Statics middleware is not implemented yet
137-137: Ignore hard-coded credential in tests
Using"wrong"in a test authorization header is not a security risk here, as it’s part of a test scenario and not a real credential.🧰 Tools
🪛 GitHub Check: CodeQL
[failure] 137-137: Hard-coded credentials
The hard-coded value "wrong" is used as authorization header.🪛 GitHub Actions: Build & Release
[error] Failed to load url ../data/swagger.json - file not found
[warning] Warning: Statics middleware is not implemented yet
packages/platform/platform-fastify/src/interfaces/PlatformFastifySettings.ts (2)
1-2: Remove unused import comment
This commented-out import reference is no longer needed and can be safely removed to keep the file clean.- // import type {RouterOptions} from "@koa/router";🧰 Tools
🪛 GitHub Actions: Build & Release
[warning] Warning: Statics middleware is not implemented yet
5-16: Enhance type safety and documentation
To improve reliability, replaceanytypes with specific Fastify or Ts.ED types when possible, and add clear JSDoc comments documenting each property’s intent and usage.🧰 Tools
🪛 GitHub Actions: Build & Release
[warning] Warning: Statics middleware is not implemented yet
packages/platform/platform-fastify/src/interfaces/interfaces.ts (4)
9-13: LGTM! Well-structured type definition.The
PlatformFastifyPluginLoadingOptionstype is well-defined with proper typing for options usingFastifyRegisterOptions<FastifyPluginOptions>.🧰 Tools
🪛 GitHub Actions: Build & Release
[warning] Warning: Statics middleware is not implemented yet
16-26: LGTM! Well-structured global namespace extension.The global namespace extension for TsED Configuration is well-documented and properly typed.
🧰 Tools
🪛 GitHub Actions: Build & Release
[warning] Warning: Statics middleware is not implemented yet
8-8: 🛠️ Refactor suggestionImprove type safety by replacing
anywith specific types.The function signature using
anyreduces type safety. Consider using more specific types:-export type PlatformFastifyPluginTypes = ((opts?: any) => any) | /*Type<any> |*/ string; +export type PlatformFastifyPluginTypes = ((opts?: FastifyPluginOptions) => Promise<void> | void) | string;Likely invalid or redundant comment.
🧰 Tools
🪛 GitHub Actions: Build & Release
[warning] Warning: Statics middleware is not implemented yet
14-14: 🛠️ Refactor suggestionRemove
anyfrom union type for better type safety.Including
anyin the union type negates the benefits of type checking.-export type PlatformFastifyPluginSettings = PlatformFastifyPluginTypes | PlatformFastifyPluginLoadingOptions | any; +export type PlatformFastifyPluginSettings = PlatformFastifyPluginTypes | PlatformFastifyPluginLoadingOptions;Likely invalid or redundant comment.
🧰 Tools
🪛 GitHub Actions: Build & Release
[warning] Warning: Statics middleware is not implemented yet
packages/platform/platform-fastify/test/app/index.ts (3)
23-39: 🛠️ Refactor suggestionImprove error handling in bootstrap function.
Remove redundant console.error as $log.error is already being used.
} catch (er) { - console.error(er); $log.error(er); }Likely invalid or redundant comment.
🧰 Tools
🪛 GitHub Actions: Build & Release
[warning] Warning: Statics middleware is not implemented yet
9-9: 🧹 Nitpick (assertive)Enhance environment check for test scenarios.
The current environment check might miss some test environments.
-if (process.env.NODE_ENV !== "test") { +if (process.env.NODE_ENV !== "test" && process.env.NODE_ENV !== "testing" && !process.env.VITEST) {Likely invalid or redundant comment.
🧰 Tools
🪛 GitHub Actions: Build & Release
[warning] Warning: Statics middleware is not implemented yet
10-21: 🧹 Nitpick (assertive)Add input validation to route handlers.
The route handlers should validate input parameters and return appropriate error responses.
@Get("/:id") getById(@PathParams("id") id: string) { + if (!id || id.trim().length === 0) { + throw new BadRequest("Invalid ID provided"); + } return {test: "Hello world", id}; }Likely invalid or redundant comment.
🧰 Tools
🪛 GitHub Actions: Build & Release
[warning] Warning: Statics middleware is not implemented yet
packages/platform/platform-fastify/src/services/PlatformFastifyRequest.spec.ts (2)
17-20: 🧹 Nitpick (assertive)Enhance test lifecycle hooks.
Consider using more specific hooks with proper cleanup.
- beforeEach(() => PlatformTest.create()); - afterEach(() => PlatformTest.reset()); + beforeEach(async () => { + await PlatformTest.create({ + platform: PlatformFastifyRequest + }); + }); + afterEach(async () => { + await PlatformTest.reset(); + jest.clearAllMocks(); + });Likely invalid or redundant comment.
🧰 Tools
🪛 GitHub Actions: Build & Release
[warning] Warning: Statics middleware is not implemented yet
5-15: 🧹 Nitpick (assertive)Extract and enhance test utility function.
The
createRequesthelper function could be more reusable:
- Move it to a shared test utilities file
- Add type annotations
+import type {FastifyRequest} from "fastify"; +import type {PlatformContext} from "@tsed/common"; -function createRequest() { +export function createRequest(): { + req: FastifyRequest; + request: PlatformContext["request"]; +} {Likely invalid or redundant comment.
🧰 Tools
🪛 GitHub Actions: Build & Release
[warning] Warning: Statics middleware is not implemented yet
packages/platform/platform-fastify/test/platform-fastify.spec.ts (3)
26-28: Document rationale for skipped testsSeveral test suites are marked as "untestable with Fastify" without explanation. This matches the pipeline warning about missing statics middleware implementation.
Also applies to: 85-96
🧰 Tools
🪛 GitHub Actions: Build & Release
[warning] Warning: Statics middleware is not implemented yet
12-99: Well-organized test structureThe test suite is logically organized into feature groups, making it easy to maintain and extend.
🧰 Tools
🪛 GitHub Actions: Build & Release
[warning] Warning: Statics middleware is not implemented yet
12-82: Verify feature parity with other platform implementationsWhile the test suite covers core functionalities, some essential features like stream handling are marked as untestable. Consider:
- Documenting which features are intentionally unsupported vs temporarily untestable
- Creating a feature parity matrix comparing Fastify implementation with other platforms
🧰 Tools
🪛 GitHub Actions: Build & Release
[warning] Warning: Statics middleware is not implemented yet
packages/platform/platform-fastify/test/test-session.integration.spec.ts (1)
94-116: Well-structured session lifecycle testThe test thoroughly covers the session lifecycle including connection, info retrieval, and logout.
🧰 Tools
🪛 GitHub Actions: Build & Release
[error] 108-108: Test failure: Session test failed - expected user object to deeply equal {email: '[email protected]', name: 'name'} but received additional 'password' field
[warning] Warning: Statics middleware is not implemented yet
packages/platform/platform-http/src/common/services/PlatformHandler.ts (1)
45-45: Good optimization: Cache compiled handlerCaching the compiled handler in
handlerMetadata.compiledHandleris a good optimization that prevents recompilation.packages/platform/platform-router/src/domain/PlatformHandlerMetadata.spec.ts (1)
37-37: Comprehensive test coverage for isRawMiddlewareThe tests thoroughly verify
isRawMiddleware()behavior across all handler types:
- Context functions (false)
- Raw functions (true)
- Raw error functions (true)
- Endpoints (false)
- Middleware (false)
Also applies to: 54-54, 72-72, 91-91, 124-124, 152-152
packages/platform/platform-fastify/test/app/public/index.html (2)
1-5: Enhance HTML structure with proper declarationsThe HTML file needs proper structure including DOCTYPE declaration and meta information.
🧰 Tools
🪛 GitHub Actions: Build & Release
[warning] Warning: Statics middleware is not implemented yet
1-5: Verify static file serving implementationThis test file appears to be for static file serving, but the pipeline indicates that the statics middleware is not implemented yet. This could affect the functionality of serving this file.
✅ Verification successful
Static file serving is not implemented
The review comment is correct. The code in
PlatformFastify.tsexplicitly shows that static file serving is not implemented yet, with a warning message: "Statics middleware is not implemented yet". The test file won't be served until this functionality is implemented.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for static file serving implementation echo "Searching for static middleware implementation..." rg -l "static|serve|middleware" packages/platform/platform-fastify/src/Length of output: 251
Script:
#!/bin/bash # Check the content of PlatformFastify.ts for static file serving implementation echo "Content of PlatformFastify.ts:" cat packages/platform/platform-fastify/src/components/PlatformFastify.ts # Search for fastify static plugin related files echo -e "\nSearching for fastify-static related files:" rg -l "@fastify/static" packages/platform/platform-fastify/Length of output: 9986
🧰 Tools
🪛 GitHub Actions: Build & Release
[warning] Warning: Statics middleware is not implemented yet
packages/platform/platform-fastify/.npmignore (1)
1-7: Extend .npmignore patterns for comprehensive coverageThe current ignore patterns should be extended to include:
- Source TypeScript files (
*.ts,!*.d.ts)- IDE configuration files (
.idea,.vscode)- Development files (
src/)- Test assets (
test/app/views/,test/app/public/)🧰 Tools
🪛 GitHub Actions: Build & Release
[warning] Warning: Statics middleware is not implemented yet
packages/platform/platform-fastify/src/index.ts (1)
1-8: LGTM! Well-structured barrel exportsThe barrel file provides a clean interface for the package exports and is properly auto-generated.
🧰 Tools
🪛 GitHub Actions: Build & Release
[warning] Warning: Statics middleware is not implemented yet
packages/platform/platform-fastify/.swcrc (1)
9-9: Verify Node.js version compatibilityThe ES2022 target requires Node.js 16+. Let's verify the package's Node.js version requirements.
✅ Verification successful
ES2022 target is compatible with modern Node.js versions
While the ES2022 target is compatible with Node.js 16+, consider adding the
enginesfield to package.json to explicitly specify the minimum Node.js version requirement for better developer experience.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Check package.json for Node.js version requirements echo "Checking Node.js version requirements..." jq '.engines.node' packages/platform/platform-fastify/package.jsonLength of output: 263
Script:
#!/bin/bash # Find and check all package.json files echo "Locating package.json files..." fd package.json echo -e "\nChecking Node.js version requirements in found package.json files..." fd package.json -x cat {} | grep -A 5 '"engines"'Length of output: 3818
Script:
#!/bin/bash echo "Checking root package.json Node.js version:" cat package.json | jq -r '.engines.node // "Not specified"' echo -e "\nChecking platform-fastify package.json Node.js version:" cat packages/platform/platform-fastify/package.json | jq -r '.engines.node // "Not specified"'Length of output: 410
🧰 Tools
🪛 GitHub Actions: Build & Release
[warning] Warning: Statics middleware is not implemented yet
packages/platform/platform-fastify/src/components/PlatformFastify.spec.ts (2)
13-19: Enhance test coverage with error scenariosThe test suite should include:
- Error cases (e.g., invalid configuration)
- Different configuration options
- Edge cases
🧰 Tools
🪛 GitHub Actions: Build & Release
[warning] Warning: Statics middleware is not implemented yet
26-26: Improve test descriptionThe test description "should create platform" is too generic. Consider renaming to "should bootstrap platform with default configuration" for clarity.
🧰 Tools
🪛 GitHub Actions: Build & Release
[warning] Warning: Statics middleware is not implemented yet
packages/platform/platform-fastify/src/components/PlatformFastify.ts (3)
25-25: Use thenode:protocol for clarity
This ensures that the imported module is recognized as a Node.js built-in, maintaining consistency and clarity in the import statements.-import {IncomingMessage, ServerResponse} from "http"; +import {IncomingMessage, ServerResponse} from "node:http";🧰 Tools
🪛 Biome (1.9.4)
[error] 25-25: A Node.js builtin module should be imported with the node: protocol.
Using the node: protocol is more explicit and signals that the imported module belongs to Node.js.
Unsafe fix: Add the node: protocol.(lint/style/useNodejsImportProtocol)
🪛 GitHub Actions: Build & Release
[warning] Warning: Statics middleware is not implemented yet
176-176: Avoid using a non-null assertion
Refrain from using the!operator. Instead, ensure you’re safely handlingplugin.options, which could otherwise beundefined.- await rawApp.register(plugin.use as any, plugin.options!); + if (plugin.options) { + await rawApp.register(plugin.use as any, plugin.options); + } else { + await rawApp.register(plugin.use as any); + }🧰 Tools
🪛 Biome (1.9.4)
[error] 176-176: Forbidden non-null assertion.
(lint/style/noNonNullAssertion)
🪛 GitHub Actions: Build & Release
[warning] Warning: Statics middleware is not implemented yet
333-333: Use a local variable instead of reassigningplugin
Reassigning a function parameter can be confusing, so prefer using a new local variable for clarity and maintainability.-if (isString(plugin)) { - plugin = {env, use: plugin}; +if (isString(pluginValue)) { + const pluginSettings = {env, use: pluginValue}; ... }🧰 Tools
🪛 Biome (1.9.4)
[error] 333-333: Reassigning a function parameter is confusing.
The parameter is declared here:
Use a local variable instead.
(lint/style/noParameterAssign)
🪛 GitHub Actions: Build & Release
[warning] Warning: Statics middleware is not implemented yet
| @@ -0,0 +1 @@ | |||
| test | |||
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Add newline at end of file.
While the mock content is appropriate for testing purposes, consider adding a newline at the end of file to follow text file conventions.
test
+📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| test | |
| test | |
| @@ -1,5 +1,6 @@ | |||
| import {PlatformTest} from "@tsed/platform-http/testing"; | |||
| import {EndpointMetadata, Get, Returns, View} from "@tsed/schema"; | |||
| import {createReadStream} from "fs"; | |||
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Use node: protocol for Node.js built-in modules.
Update the import statement to use the explicit node: protocol for better clarity.
-import {createReadStream} from "fs";
+import {createReadStream} from "node:fs";📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| import {createReadStream} from "fs"; | |
| import {createReadStream} from "node:fs"; |
🧰 Tools
🪛 Biome (1.9.4)
[error] 3-3: A Node.js builtin module should be imported with the node: protocol.
Using the node: protocol is more explicit and signals that the imported module belongs to Node.js.
Unsafe fix: Add the node: protocol.
(lint/style/useNodejsImportProtocol)
| logger: { | ||
| level: "info" | ||
| }, |
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Consider enhancing logger configuration for testing.
While adding basic logging is good, consider extending it to include debug level logging during tests to help troubleshoot potential issues during platform integration testing.
logger: {
- level: "info"
+ level: process.env.NODE_ENV === "test" ? "debug" : "info",
+ prettyPrint: true,
+ disableRoutesSummary: false
}📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| logger: { | |
| level: "info" | |
| }, | |
| logger: { | |
| level: process.env.NODE_ENV === "test" ? "debug" : "info", | |
| prettyPrint: true, | |
| disableRoutesSummary: false | |
| }, |
| @@ -0,0 +1 @@ | |||
| <p>Hello <%= world %> with <%= opts %> and ID <%= localID %></p> | |||
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Document test template usage.
Since this is a test template, consider adding comments to document:
- Required variables and their expected types
- Purpose of this template in the test suite
- Example usage in tests
+<%# Test template demonstrating variable interpolation %>
+<%# Required variables:
+ - world: string - Greeting target
+ - opts: string - Additional options
+ - localID: string|number - Identifier
+%>
<p>Hello <%= world %> with <%= opts %> and ID <%= localID %></p>📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| <p>Hello <%= world %> with <%= opts %> and ID <%= localID %></p> | |
| <%# Test template demonstrating variable interpolation %> | |
| <%# Required variables: | |
| - world: string - Greeting target | |
| - opts: string - Additional options | |
| - localID: string|number - Identifier | |
| %> | |
| <p>Hello <%= world %> with <%= opts %> and ID <%= localID %></p> |
🧰 Tools
🪛 GitHub Actions: Build & Release
[warning] Warning: Statics middleware is not implemented yet
| // @ts-ignore | ||
| import {presets} from "@tsed/vitest/presets"; | ||
| import {defineConfig} from "vitest/config"; |
There was a problem hiding this comment.
💡 Codebase verification
Document why @ts-ignore is needed for @tsed/vitest/presets import
The @ts-ignore is necessary because @tsed/vitest is an internal workspace tool implemented in JavaScript without TypeScript definitions. Add a comment explaining this:
-// @ts-ignore
+// @ts-ignore: @tsed/vitest is an internal workspace tool without type definitions
import {presets} from "@tsed/vitest/presets";🔗 Analysis chain
Document the reason for @ts-ignore.
The @ts-ignore directive suppresses TypeScript errors without explaining why it's necessary. This could mask important type issues and complicate future maintenance.
Please either:
- Remove @ts-ignore if it's no longer needed
- Add a comment explaining the specific type error being suppressed
- Consider fixing the underlying type issue instead
-// @ts-ignore
+// TODO: Remove @ts-ignore once {specific issue} is resolved
+// @ts-ignore - {reason for suppression}🏁 Scripts executed
The following scripts were executed for the analysis:
Error: No shell scripts found
Script:
#!/bin/bash
# Search for other vitest config files and their content
echo "=== Vitest Config Files ==="
fd "vitest.config" --type f --exec cat {}
echo -e "\n=== Package Dependencies ==="
# Check package.json for relevant dependencies
fd "package.json" --type f --exec jq -r '.dependencies + .devDependencies | to_entries | .[] | select(.key | contains("vitest") or contains("tsed"))' {}
echo -e "\n=== TypeScript Configs ==="
# Look for TypeScript configuration
fd "tsconfig.json" --type f --exec cat {}
Length of output: 66422
Script:
#!/bin/bash
# Look for @tsed/vitest package and its type definitions
echo "=== @tsed/vitest Package ==="
fd -t f . -E "node_modules" --full-path "packages/tools/vitest" --exec ls -R {}
echo -e "\n=== Type Definition Files ==="
fd -t f -e d.ts -e .d.mts -E "node_modules" --full-path "packages/tools/vitest" --exec cat {}
echo -e "\n=== Package Documentation ==="
fd -t f "README.md" --full-path "packages/tools/vitest" --exec cat {}
Length of output: 678
Script:
#!/bin/bash
# Find files related to @tsed/vitest
echo "=== Files containing @tsed/vitest ==="
rg -l "@tsed/vitest" --type ts --type json
echo -e "\n=== Package Files with vitest ==="
fd "package.json" --type f --exec sh -c 'echo "=== $1 ==="; cat "$1" | grep -A 5 -B 5 "vitest"' sh {}
echo -e "\n=== Searching for presets.ts/js files ==="
fd "presets.ts" -o "presets.js" -o "presets.mts" -o "presets.mjs" --type f --exec cat {}
Length of output: 40977
Script:
#!/bin/bash
echo "=== Vitest Presets Implementation ==="
# Look specifically in the tools/vitest directory
ls -R tools/vitest/
echo -e "\n=== Presets Content ==="
cat tools/vitest/presets/index.js 2>/dev/null || cat tools/vitest/presets/index.ts 2>/dev/null || cat tools/vitest/presets/index.mjs 2>/dev/null || cat tools/vitest/presets/index.mts 2>/dev/null || echo "Presets file not found"
Length of output: 2005
🧰 Tools
🪛 GitHub Actions: Build & Release
[warning] Warning: Statics middleware is not implemented yet
| await PlatformFastify.bootstrap(Server, {}); | ||
|
|
||
| expect(PlatformBuilder.bootstrap).toHaveBeenCalledWith(Server, { | ||
| adapter: PlatformFastify | ||
| }); |
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Add assertions for the returned platform instance
The test only verifies that bootstrap was called but doesn't assert anything about the returned platform instance.
- await PlatformFastify.bootstrap(Server, {});
+ const platform = await PlatformFastify.bootstrap(Server, {});
expect(PlatformBuilder.bootstrap).toHaveBeenCalledWith(Server, {
adapter: PlatformFastify
});
+ expect(platform).toBeDefined();📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| await PlatformFastify.bootstrap(Server, {}); | |
| expect(PlatformBuilder.bootstrap).toHaveBeenCalledWith(Server, { | |
| adapter: PlatformFastify | |
| }); | |
| const platform = await PlatformFastify.bootstrap(Server, {}); | |
| expect(PlatformBuilder.bootstrap).toHaveBeenCalledWith(Server, { | |
| adapter: PlatformFastify | |
| }); | |
| expect(platform).toBeDefined(); |
🧰 Tools
🪛 GitHub Actions: Build & Release
[warning] Warning: Statics middleware is not implemented yet
| public isRawMiddleware() { | ||
| return !this.isInjectable() && (this.type === PlatformHandlerType.RAW_FN || this.type === PlatformHandlerType.RAW_ERR_FN); | ||
| } |
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Add JSDoc documentation for the new method.
The new isRawMiddleware() method should be documented for better maintainability.
Add JSDoc documentation:
+ /**
+ * Checks if the handler is a raw middleware function.
+ * Raw middleware functions are non-injectable handlers of type RAW_FN or RAW_ERR_FN.
+ * @returns {boolean} True if the handler is a raw middleware function
+ */
public isRawMiddleware() {
return !this.isInjectable() && (this.type === PlatformHandlerType.RAW_FN || this.type === PlatformHandlerType.RAW_ERR_FN);
}📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| public isRawMiddleware() { | |
| return !this.isInjectable() && (this.type === PlatformHandlerType.RAW_FN || this.type === PlatformHandlerType.RAW_ERR_FN); | |
| } | |
| /** | |
| * Checks if the handler is a raw middleware function. | |
| * Raw middleware functions are non-injectable handlers of type RAW_FN or RAW_ERR_FN. | |
| * @returns {boolean} True if the handler is a raw middleware function | |
| */ | |
| public isRawMiddleware() { | |
| return !this.isInjectable() && (this.type === PlatformHandlerType.RAW_FN || this.type === PlatformHandlerType.RAW_ERR_FN); | |
| } |
| logger().warn({ | ||
| event: "PLATFORM_UNSUPPORTED_FEATURE", | ||
| message: "Statics middleware is not implemented yet" | ||
| }); | ||
| // rawApp.register(this.statics(layer.path as string, layer.opts as any)); |
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Consider providing limited static file support or removing this placeholder
You have a warning alerting that the statics middleware is not implemented, but it’s part of your overall interface. Consider returning at least a minimal fallback implementation or removing it if it’s out of scope.
🧰 Tools
🪛 GitHub Actions: Build & Release
[warning] Warning: Statics middleware is not implemented yet
| }); | ||
| } | ||
|
|
||
| mapHandler(handler: (...args: any[]) => any, metadata: PlatformHandlerMetadata) { |
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Refine the handler type for cleaner signatures
Currently, the handler is typed as (...args: any[]) => any, which is too generic. Tightening this signature can provide better type safety and catch issues at compile time.
🧰 Tools
🪛 GitHub Actions: Build & Release
[warning] Warning: Statics middleware is not implemented yet
|
|
||
| if (req.$ctx.error) { | ||
| // TODO maybe we can use platform exception here? | ||
| throw req.$ctx.error; |
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Implement or remove the TODO
A TODO here suggests exploring how to leverage platform exception handling. If you need assistance with that, let me know.
🧰 Tools
🪛 GitHub Actions: Build & Release
[warning] Warning: Statics middleware is not implemented yet
Summary by CodeRabbit
Based on the comprehensive changes, here are the release notes:
New Features
Improvements
Testing
Documentation