-
Notifications
You must be signed in to change notification settings - Fork 48
Move to new angular build executor #52
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -5,4 +5,5 @@ | |
|
||
.angular | ||
|
||
/.nx/cache | ||
/.nx/cache | ||
/.nx/workspace-data |
This file was deleted.
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,3 @@ | ||
import { app } from '../dist/docs-static/server/server.mjs'; | ||
|
||
export default app(); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 🛠️ Refactor suggestion Reconsider immediate invocation of The current implementation immediately invokes the
Consider exporting the import { app } from '../dist/docs-static/server/server.mjs';
export default app; Then, in the file where you actually want to start the server: import app from './api/index.mjs';
try {
const server = app();
// Additional setup or logging can be done here
} catch (error) {
console.error('Failed to start the server:', error);
} This approach provides better control over the server startup process and allows for proper error handling. |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,3 +1,4 @@ | ||
/* eslint-disable @typescript-eslint/unbound-method */ | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 💡 Codebase verification Remove the global ESLint disable directive for Disabling the Analysis chainConsider removing ESLint disable directives A new ESLint disable directive has been added for the Consider addressing the underlying issues that trigger these ESLint warnings instead of disabling them. If these rules are consistently problematic for your project, it might be better to configure them in your ESLint configuration file rather than using inline disable comments. To help identify where these ESLint rules are being triggered, you can run the following command: This will help you locate potential instances where the Scripts executedThe following scripts were executed for the analysis: Script: #!/bin/bash
# Search for usage of methods that might trigger the unbound-method rule
rg --type typescript '\b(this\.[a-zA-Z_]\w*|[a-zA-Z_]\w*\.[a-zA-Z_]\w*)\s*[,)]' ./src
Length of output: 122 Script: #!/bin/bash
# Search for usage of methods that might trigger the unbound-method rule in TypeScript files
rg '\b(this\.[a-zA-Z_]\w*|[a-zA-Z_]\w*\.[a-zA-Z_]\w*)\s*[,)]' ./src -g '*.ts' -g '*.tsx'
Length of output: 136 Script: #!/bin/bash
# Search for usage of methods that might trigger the unbound-method rule in all TypeScript files
rg '\b(this\.[a-zA-Z_]\w*|[a-zA-Z_]\w*\.[a-zA-Z_]\w*)\s*[,)]' . -g '*.ts' -g '*.tsx'
Length of output: 21597 |
||
/* eslint-disable @typescript-eslint/no-unsafe-argument */ | ||
/* eslint-disable @typescript-eslint/no-unsafe-assignment */ | ||
/* eslint-disable @typescript-eslint/no-unsafe-call */ | ||
|
This file was deleted.
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,2 @@ | ||
export { FlowbiteRouterLinkActiveDirective } from './flowbite-router-link-active.directive'; | ||
export { FlowbiteRouterLinkDirective } from './flowbite-router-link.directive'; | ||
Comment on lines
+1
to
+2
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 💡 Codebase verification Custom router link directives are implemented and declared but currently unused. The Analysis chainLGTM! Consider verifying directive implementations. The export statements for the custom router link directives look good. They follow a consistent naming convention and are likely part of integrating Flowbite with Angular's routing system. To ensure these directives are properly implemented and used, consider running the following verification: This script will help verify:
Please review the results to ensure proper implementation and usage throughout the project. Scripts executedThe following scripts were executed for the analysis: Script: #!/bin/bash
# Description: Verify the implementation and usage of the custom router link directives
# Check the implementation of the directives
echo "Checking FlowbiteRouterLinkActiveDirective implementation:"
ast-grep --lang typescript --pattern 'class FlowbiteRouterLinkActiveDirective {
$$$
}'
echo "Checking FlowbiteRouterLinkDirective implementation:"
ast-grep --lang typescript --pattern 'class FlowbiteRouterLinkDirective {
$$$
}'
# Check for usage of the directives in component templates
echo "Checking usage of FlowbiteRouterLinkActiveDirective:"
rg --type html 'flowbiteRouterLinkActive'
echo "Checking usage of FlowbiteRouterLinkDirective:"
rg --type html 'flowbiteRouterLink'
# Check if the directives are declared in any Angular modules
echo "Checking if directives are declared in Angular modules:"
rg --type typescript '(FlowbiteRouterLinkActiveDirective|FlowbiteRouterLinkDirective)' -C 5
Length of output: 4885 Script: #!/bin/bash
# Description: Re-verify the implementation and usage of the custom router link directives with corrected rg commands
# Check the implementation of the directives
echo "Checking FlowbiteRouterLinkActiveDirective implementation:"
ast-grep --lang typescript --pattern 'class FlowbiteRouterLinkActiveDirective {
$$$
}'
echo "Checking FlowbiteRouterLinkDirective implementation:"
ast-grep --lang typescript --pattern 'class FlowbiteRouterLinkDirective {
$$$
}'
# Check for usage of the directives in component templates
echo "Checking usage of FlowbiteRouterLinkActiveDirective:"
rg --glob '*.html' 'flowbiteRouterLinkActive'
echo "Checking usage of FlowbiteRouterLinkDirective:"
rg --glob '*.html' 'flowbiteRouterLink'
# Check if the directives are declared in any Angular modules
echo "Checking if directives are declared in Angular modules:"
rg --glob '*.ts' '(FlowbiteRouterLinkActiveDirective|FlowbiteRouterLinkDirective)' -C 5
Length of output: 23519 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🛠️ Refactor suggestion
Consider using a more robust import path
The current import statement uses a relative path that points to a compiled version of the server. This approach might be brittle if the project structure changes.
Consider using a more robust import method, such as aliasing the import path in your build configuration or using a module resolution plugin. This would make the import less dependent on the exact file structure.
For example, you could use a path alias:
And configure the alias in your build tool or TypeScript configuration.