Move to new angular build executor #52
Conversation
|
Someone is attempting to deploy a commit to the Themesberg Team on Vercel. A member of the Team first needs to authorize it. |
WalkthroughThe changes involve updates to various configuration files and the restructuring of application entry points in an Angular project. Key modifications include the addition of new server and build configurations, the introduction of a new entry point for the application, and updates to dependency versions. Additionally, the Changes
Possibly related PRs
Poem
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
Documentation and Community
|
|
@coderabbitai review |
Actions performedReview triggered.
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 4
Outside diff range and nitpick comments (8)
vercel.json (1)
5-8: LGTM! Consider caching dependencies.The new configuration looks good. The framework is correctly set to Angular, and the build and install commands are consistent with using Yarn and Nx.
To potentially improve build times, consider adding a
cacheDirectoriesproperty to cache thenode_modulesfolder:"installCommand": "yarn install", + "cacheDirectories": [".yarn/cache", "node_modules"]This can speed up subsequent deployments by reusing cached dependencies.
apps/docs/tailwind.config.js (3)
Line range hint
15-15: Review and optimize the safelistThe
safelistarray contains a mix of utility classes. While safelisting ensures these classes are always included in the CSS output, it can increase the size of your CSS file unnecessarily if not all of these classes are dynamically used.Consider reviewing this list and removing any classes that are not dynamically generated or used in your application. If these classes are used in a specific component or feature, you might want to move them to a more localized safelist using the
safelistoption in thecontentconfiguration.Example of a more specific safelist:
content: [ // ... other content configurations { files: ['./src/app/specific-component/**/*.{html,ts}'], safelist: ['p-4', 'overflow-x-auto', 'rounded-md', 'max-w-md', 'max-w-sm'] }, { files: ['./src/app/another-component/**/*.{html,ts}'], safelist: ['bg-gray-100', 'bg-gray-500', 'z-0'] } ]This approach can help reduce the CSS file size while ensuring necessary classes are included.
Line range hint
13-13: Consider using more specific content pathsThe current content configuration uses a broad pattern to include all non-test and non-story files in the src directory.
For better performance and to avoid potential inclusion of unnecessary files, consider using more specific paths in your content configuration. This can help reduce build time and final bundle size.
Example of a more specific content configuration:
content: [ join(__dirname, 'src/app/**/*.{html,ts}'), join(__dirname, 'src/components/**/*.{html,ts}'), ...createGlobPatternsForDependencies(__dirname) ],This approach explicitly includes only the app and components directories, which are likely to contain the majority of your Tailwind CSS usage.
Line range hint
7-9: Consider using import statements instead of requireThe configuration file uses
requireto import modules, which is the CommonJS way of importing modules. While this works, using ES6 import statements can provide better static analysis and tree-shaking opportunities.Consider updating the import statements to use ES6 syntax. This would require changing the file extension to
.mjsor adding"type": "module"to yourpackage.json. Here's an example of how it could look:import { createGlobPatternsForDependencies } from '@nx/angular/tailwind'; import { join } from 'path'; import sharedTailwindConfig from '../../libs/flowbite-angular/tailwind.config.js';Note that you'll need to ensure that the imported modules support ES modules. This change can potentially improve build-time optimizations and align with modern JavaScript practices.
apps/docs/server.ts (4)
13-15: Path resolution logic improved.The new approach for resolving server and browser distribution folders is more robust:
- Using
fileURLToPathanddirnameensures correct path resolution in different environments.- The browser distribution folder is now correctly resolved relative to the server folder.
- Simplifying the
indexHtmlassignment improves code clarity.These changes enhance the reliability of file path handling.
Consider using
path.join()forindexHtmlassignment for better cross-platform compatibility:- const indexHtml = join(serverDistFolder, 'index.server.html'); + const indexHtml = join(serverDistFolder, 'index.server.html');
26-29: Static file serving configuration improved.The changes to the static file serving configuration enhance the server's behavior:
- Using '**' as the route pattern ensures all static files are served correctly.
- Specifying 'index.html' as the default file improves the handling of directory requests.
These updates provide a more robust static file serving setup.
Consider adding the
fallthrough: trueoption to allow non-existent files to be handled by subsequent middleware:server.get( '**', express.static(browserDistFolder, { maxAge: '1y', index: 'index.html', + fallthrough: true, }), );This ensures that Angular's routing can handle routes that don't correspond to static files.
62-62: Server execution simplified.Adding the
run();call at the end of the file simplifies the server's execution flow. This change removes the need for a conditional check to determine if the server should be started, making the code more straightforward.Consider adding a comment explaining why the server is always started, especially if this file might be imported elsewhere:
+ // Always start the server when this file is the main module run();This helps clarify the intention behind this unconditional execution.
Line range hint
1-62: Overall improvements to server configuration and file handling.The changes in this file significantly enhance the server setup:
- Improved path resolution using
fileURLToPathanddirname.- Better static file serving with more inclusive routing.
- Updated Angular route handling to capture all routes.
- Simplified server execution flow.
These updates align the server configuration with best practices and improve the overall robustness of the application. The changes are well-considered and should lead to more reliable server behavior.
Consider adding error handling middleware after your routes to catch any unhandled errors:
server.use((err, req, res, next) => { console.error(err.stack); res.status(500).send('Something broke!'); });This would improve the error handling capabilities of your server.
Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Files selected for processing (13)
- .prettierignore (1 hunks)
- api/index.js (0 hunks)
- api/index.mjs (1 hunks)
- apps/docs/project.json (2 hunks)
- apps/docs/server.ts (2 hunks)
- apps/docs/tailwind.config.js (1 hunks)
- apps/docs/tsconfig.app.json (1 hunks)
- apps/docs/tsconfig.json (1 hunks)
- apps/docs/tsconfig.server.json (0 hunks)
- libs/flowbite-angular/src/index.ts (1 hunks)
- libs/flowbite-angular/src/lib/directives/index.ts (1 hunks)
- package.json (2 hunks)
- vercel.json (1 hunks)
Files not reviewed due to no reviewable changes (2)
- api/index.js
- apps/docs/tsconfig.server.json
Additional comments not posted (20)
.prettierignore (1)
8-9: LGTM! Appropriate additions to .prettierignoreThe changes to the
.prettierignorefile are appropriate and align with best practices for Nx-based projects:
/.nx/cache: This directory typically contains cached build artifacts and should not be formatted./.nx/workspace-data: This likely contains workspace-specific data that also doesn't require formatting.Ignoring these directories will improve Prettier's performance by skipping unnecessary files and prevent any potential issues with formatting generated content.
libs/flowbite-angular/src/index.ts (1)
6-6: LGTM! Consider verifying for potential naming conflicts.The addition of
export * from './lib/directives';is consistent with the existing export pattern and expands the public API of the module to include directives. This change enhances the functionality available to users of the library.To ensure this change doesn't introduce any naming conflicts, please run the following verification script:
This script will help identify any potential naming conflicts across the exported entities. If any conflicts are found, please resolve them to prevent breaking changes.
apps/docs/tsconfig.app.json (2)
9-9: LGTM! Verify Server-Side Rendering (SSR) setup.The addition of "src/main.server.ts" and "server.ts" to the "files" array suggests that the project is being set up for server-side rendering (SSR) or Angular Universal. This change is correct for SSR setups.
To ensure this change is properly implemented, please run the following script to verify the SSR setup:
#!/bin/bash # Description: Verify Server-Side Rendering (SSR) setup # Check if the new files exist echo "Checking for SSR-related files:" fd -t f "(main\.server\.ts|server\.ts)" src # Search for SSR-related imports and configurations echo "Searching for SSR-related code:" rg --type typescript '(platformServer|renderModule|APP_BASE_HREF|ServerModule|provideServerRendering)' -g '!node_modules' # Check for SSR-related dependencies in package.json echo "Checking for SSR-related dependencies:" jq '.dependencies | keys[] | select(. | test("@angular/platform-server|@nguniversal"))' package.json
5-5: LGTM! Verify Node.js usage in the project.The addition of "node" to the "types" array is correct for projects using Node.js APIs or Angular Universal. This change allows the use of Node.js types in the application.
To ensure this change is necessary, please run the following script to check for Node.js usage in the project:
Verification successful
Verification Successful: Angular Universal is configured.
The presence of
@angular/platform-serverinpackage.jsonconfirms that Angular Universal is set up for server-side rendering. Although initial script errors occurred, the necessary SSR dependencies are present, validating the addition of"node"to the"types"array.Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check for Node.js API usage in the project # Search for common Node.js APIs in TypeScript files echo "Searching for Node.js API usage:" rg --type typescript -i '(require|process|buffer|fs|path|os|crypto|http|https|net|dgram|dns|tls|cluster|child_process|stream|util|events|assert|zlib|readline|repl|vm|punycode|url|querystring|string_decoder|worker_threads)\.' -g '!node_modules' # Check if the project uses Angular Universal echo "Checking for Angular Universal setup:" rg --type typescript 'platformServer|renderModule|APP_BASE_HREF' -g '!node_modules'Length of output: 658
vercel.json (3)
19-19: LGTM! Verify module imports for compatibility.The change from
.jsto.mjsfor the API function is a good move towards using ECMAScript modules. This can lead to better tree-shaking and module resolution.To ensure this change doesn't break any existing imports or require additional configuration changes, please run the following command to check for any references to the old file name:
If any results are found, those files may need to be updated to use the new
.mjsextension.Verification successful
Change Verified: File Extension Update
The search for references to
api/index.jsreturned no results, confirming that the update to.mjsdoes not affect existing imports.Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for references to the old API file name rg "api/index\.js"Length of output: 187
Script:
#!/bin/bash # Search for references to the old API file name rg "api/index\.js"Length of output: 20
9-11: Clarify the use of the "canary" runtime tag.The addition of environment variables is a good practice. However, the use of the "canary" tag for
FORCE_RUNTIME_TAGraises some concerns:
- Canary versions are typically unstable and meant for testing, not production use.
- This could lead to unexpected behavior or instability in the deployed application.
Could you please clarify the reason for using the "canary" tag? If this is intentional, consider adding a comment explaining the decision. If it's not required, it might be safer to remove this environment variable or use a stable version tag.
To check if this tag is used elsewhere in the project, you can run:
20-20: Verify the necessity of including all files in dist/docs-static.The change to include all files under
dist/docs-static/**instead of just those underdist/docs-static/browser/**makes the deployment more inclusive. This could be intentional if the build output structure has changed or if additional files are now required.However, to ensure we're not unnecessarily increasing the deployment size, please verify that all files under
dist/docs-static/are indeed required for the deployment. You can run the following command to list the directory structure after building:Review the output to confirm that all directories and files are necessary for the deployment. If you find any unnecessary files, consider updating the
includeFilespath to be more specific or add them to a.vercelignorefile.apps/docs/tsconfig.json (1)
27-28: Approved: Good addition for improved module interoperabilityThe addition of
"esModuleInterop": trueis a positive change. This compiler option enhances the interoperability between CommonJS and ES Modules, which can lead to more flexible and cleaner import statements in your TypeScript code. It's particularly useful when working with libraries that use different module systems.Benefits include:
- Simplified import syntax for CommonJS modules.
- Better compatibility with various third-party libraries.
- Reduced need for
import * assyntax.This change aligns well with the modern ES2022 target you're using and is a recommended setting for most TypeScript projects.
apps/docs/server.ts (3)
5-5: Import statements updated correctly.The changes to the import statements are appropriate:
- Using default import for Express is a good practice.
- The new imports for path and URL manipulation are necessary for the updated path resolution logic.
These changes improve code clarity and provide the required functionality for the file path handling updates.
Also applies to: 7-8
20-20: View engine configuration updated correctly.The change to use
browserDistFolderfor the views setting is appropriate and aligns with the new folder structure. This ensures that Express serves views from the correct directory.
34-34: Angular route handling updated correctly.The changes to the Angular route handling improve the server's behavior:
- Using '**' as the route pattern ensures all routes are properly captured and handled by Angular.
- Updating to
browserDistFolderaligns with the new folder structure and naming conventions.These changes ensure proper routing for the Angular application.
Also applies to: 42-42
apps/docs/project.json (5)
Line range hint
72-89: Removal of server, prerender, and start targets - Verify no breaking changesThe
server,prerender, andstarttargets have been removed from the configuration. This is likely due to the consolidation of server-side rendering and serving capabilities into the new build and serve configurations.To ensure this removal doesn't introduce breaking changes:
- Check if any existing scripts or CI/CD processes rely on these removed targets.
- Verify that all functionalities previously provided by these targets are now covered by the new configurations.
If any usages are found, they will need to be updated to use the new build and serve configurations.
10-11: Significant changes to build configuration - Verify build processThe build executor has been updated to use
@angular-devkit/build-angular:application, and the output path structure has been modified. These changes align with the PR objective of moving to a new Angular build executor.To ensure these changes don't introduce any unexpected issues:
- Verify that the build process completes successfully with the new configuration.
- Check that the output files are generated in the expected location (
dist/docs-static).
61-71: New serve target added - Verify serving functionalityA new
servetarget has been added with configurations for both production and development environments. This addition improves the flexibility of the development process and aligns with modern Angular development practices.To ensure the new serve configurations work correctly:
Line range hint
72-89: Unchanged targets - Verify compatibility with new build configurationThe
test,extract-i18n, andlinttargets remain unchanged in this update. While this suggests that these processes are not directly affected by the new build executor, it's important to verify their compatibility with the new configuration.To ensure these unchanged targets still function correctly:
If any of these commands fail, it may indicate compatibility issues with the new build configuration that need to be addressed.
13-15: New build options added - Verify SSR and prerendering functionalitySeveral new build options have been introduced:
- A new
outputPathstructure with abaseproperty.- Updated
polyfillsto only include "zone.js".- New options for
browser,server,prerender, andssr.These changes suggest a shift towards server-side rendering (SSR) and prerendering capabilities. The polyfills change might affect browser compatibility.
To ensure these new options work as expected:
- Verify that SSR and prerendering are functioning correctly.
- Check for any browser compatibility issues due to the polyfills change.
Also applies to: 17-17, 22-28
package.json (4)
Line range hint
1-95: Summary of package.json updatesThe changes in this file primarily consist of version updates for various dependencies and devDependencies. Key points:
- Angular core packages have been updated to 18.2.5.
- Nx packages have been updated to 19.8.0.
- TypeScript has been updated to 5.4.5.
- A new dependency, @typescript-eslint/utils, has been added.
These updates should improve the project's tooling and potentially introduce new features. However, it's important to:
- Test the build process thoroughly to ensure compatibility.
- Review the changelogs of major updates (especially Nx and TypeScript) for any breaking changes or new features that could benefit the project.
- Update the linting configuration if necessary due to the new ESLint utility package.
Overall, these changes appear to be positive improvements to the project's dependencies.
Line range hint
77-95: LGTM! Consider exploring new TypeScript features.The updates to ng-packagr (18.2.1), nx (19.8.0), and especially TypeScript (5.4.5) are approved. With the TypeScript update, you might want to explore any new language features or type checking improvements that could benefit your project.
To ensure compatibility with the new TypeScript version, run the following command:
#!/bin/bash # Description: Verify TypeScript compilation with the new version npx tsc --noEmitThis will perform a type-check of your project without emitting files, helping to catch any potential issues with the new TypeScript version.
43-65: New ESLint utility package added. Consider updating linting configuration.The addition of
@typescript-eslint/utils@^7.16.0suggests new linting capabilities or requirements. Please ensure that your ESLint configuration is updated to take advantage of any new features or rules provided by this package.To verify if the linting configuration needs updates, run the following command:
#!/bin/bash # Description: Check for any linting errors with the new configuration npm run lintIf there are any new errors or warnings, you may need to update your ESLint configuration.
24-35: LGTM! Consider reviewing changelogs for significant updates.The updates to Angular core packages (from 18.0.x to 18.2.5) and @nx/angular (from 19.1.1 to 19.8.0) are minor version bumps, which should be backwards compatible. However, it's worth reviewing the changelogs for these packages to be aware of any new features or potential breaking changes, especially for the more significant @nx/angular update.
To ensure there are no unexpected breaking changes, you can run the following command to check if the application builds successfully with the new dependencies:
| @@ -0,0 +1,3 @@ | |||
| import { app } from '../dist/docs-static/server/server.mjs'; | |||
There was a problem hiding this comment.
🛠️ 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:
import { app } from '@server/server.mjs';And configure the alias in your build tool or TypeScript configuration.
| @@ -0,0 +1,3 @@ | |||
| import { app } from '../dist/docs-static/server/server.mjs'; | |||
|
|
|||
| export default app(); | |||
There was a problem hiding this comment.
🛠️ Refactor suggestion
Reconsider immediate invocation of app()
The current implementation immediately invokes the app() function and exports its result. This approach has potential drawbacks:
- It may cause side effects upon import, which can be unexpected.
- There's no error handling around the
app()invocation. - It doesn't allow for any configuration or setup before starting the server.
Consider exporting the app function itself instead of its invocation result. This would allow more flexibility in how and when the server is started. For example:
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.
| export { FlowbiteRouterLinkActiveDirective } from './flowbite-router-link-active.directive'; | ||
| export { FlowbiteRouterLinkDirective } from './flowbite-router-link.directive'; |
There was a problem hiding this comment.
💡 Codebase verification
Custom router link directives are implemented and declared but currently unused.
The FlowbiteRouterLinkActiveDirective and FlowbiteRouterLinkDirective are properly implemented and declared in Angular modules. However, they are not found to be used in any component templates. Please verify whether these directives are intended for future use or consider removing them to avoid unnecessary code in the codebase.
Analysis chain
LGTM! 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:
- The implementation of both directives
- Their usage in component templates
- Their declaration in Angular modules
Please review the results to ensure proper implementation and usage throughout the project.
Scripts executed
The 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
| @@ -1,3 +1,4 @@ | |||
| /* eslint-disable @typescript-eslint/unbound-method */ | |||
There was a problem hiding this comment.
💡 Codebase verification
Remove the global ESLint disable directive for @typescript-eslint/unbound-method
Disabling the @typescript-eslint/unbound-method rule globally can conceal potential issues across the codebase. Instead, consider addressing the specific instances where this rule is triggered or configure the rule in your ESLint settings to better suit the project's needs.
Analysis chain
Consider removing ESLint disable directives
A new ESLint disable directive has been added for the @typescript-eslint/unbound-method rule. While this may temporarily solve a linting issue, it's generally not recommended to disable ESLint rules globally in a configuration file.
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 unbound-method rule might be triggered, allowing you to address them directly rather than disabling the rule.
Scripts executed
The 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
* docs: rework front update routing * style: edit eslint and prettier config * test: fix test for components after update * refactor: clean html template with prettier conf * perf: remove unused dependencies * fix: development/production config with nx start * docs: add icons from figma * docs: remove svg dark:hidden * docs: make home page responsive for mobile * docs: update home page responsive tablet * docs: add responsive laptop screen * docs: fix display block img * docs: simplify css home page * docs: clean imports and export library * feat: upgrade to nx 19 * feat: upgrade to angular 18 * feat: migrate sidebar service to signal style * fix: fix eslint comment * feat: migrate alert to signal * feat: migrate component to input style * fix: update project.json to build * refactor: component code * fix: theme local storage * feat: clean accordion component / signal service * refactor: clean theme component's part * refactor: add region to component's theme * refactor: remove direct call to Flowbite varients * feat: theme service implementation for components * feat: add Combination type * feat: switch from interface to type * feat: using Combination * feat: add [key: string]: string to component parameter types * feat: update navbar and add navbar toggle * refactor: clean input name and add link service * feat: migrate input and directive to new style sys * fix: rollback generateId in onInit * fix: crypto is not defined * feat: move to shiki and restyle input-field * feat: add some documentation + update library components * feat: add default tailwind conf for library * refactor: new prettier and lint config * feat: add CodeRabbit configuration * feat: move common into shared * refactor: update remove .tsx fils from eslint config * feat: update badge documentation * feat: update accordion documentation page * feat: update alert documentation page * feat: update breadcrumb documentation page * feat: update button documentation page * feat: update dropdown documentation page * feat: update indicator documentation page * feat: update modal documentation page * fix(docs): clip display example * refactor: auto close html tag * feat(â�docs): use iframe * feat(docs): add control panel on preview * feat(docs): add dark mode to iframe * feat: update breadcrumb documentation page * feat: update button documentation page * feat: update dropdown documentation page * feat: update modal documentation page * feat(docs): add size demo * feat(docs): update frame display height * feat(docs): get icons from flowbite-icon without size and color * feat: update usage of icons * feat: create IconComponent & single template file * refactor: remove img sun * refactor: format frame html code * feat: update icons in frame display * refactor: reorder class's member * feat: use IconComponent in other components * feat: many things after git crash lost commits :/ * docs(alert): complete alert documentation * docs(alert): re-add dismissable alerts section * docs: move github files to .github dir * feat: move to structural directive for routable components * feat: use RouterLink directive as HostDirective * docs: add override-base-style page * docs: fix w-full & add fragment anchor * feat: move from aliases to colors * feat: fix color call of config * feat: from baseComponent to baseDirective * feat: simplify theme files * docs: fix customStyle * feat: add dark and primary to colors of component * fix: breadcrumb style * fix: indicator offset * feat: add sidebar-menu and add mobile support for docs * fix(sidebar): fix autoclose on click * fix: mobile display * fix: mobile display * fix(sidebar): scrollable if opened * fix(sidebar): shrink-0 * feat(accordion): add isAlwaysOpen & clean classes * refactor: make all inject public * docs(accordion): add always open doc * docs: simplify example setup * docs(accordion): add color and flush accordion example * feat: move baseComponent to directive * feat: add init and verify function (see AccordionComponent) * feat: move to inject component instead of themeServices * docs: resize iframe for updated components * docs: add shiki theme on components * docs: add customStyle usage * feat(sidebar): add RouterLinkActive to items (not binded yet on isActive in theme) * feat(sidebar): add color and auto open if active * feat: moe from input boolean | string to unknown * feat: change default color to get parent's one * feat(breadcrumb): add color support * fix(indicator): display with text and default color * fix: prerender error with assets not being found * feat(navbar): add routerLinkActive like sidebar * docs: make iframe full height * refactor: change to anchor href for redirect * feat(dropdown): update divider and finish doc * feat: modal docs * docs: added title on pages * refactor: little fixes * docs: add table of content * feat: add flowbiterouterlink with href for external link * feat(ui): Navbar layout, navbar icons and small styling changes (#50) * feat(ui): update navbar layout * feat(ui): add navbar icon buttons for resources * feat(ui): change sidebar border-r colour to match figma * feat(ui): address PR comments * feat(ui): update ui component html --------- Co-authored-by: MGREMY <[email protected]> * feat(ui): add copy package input component (#51) * feat(ui): update navbar layout * feat(ui): add navbar icon buttons for resources * feat(ui): change sidebar border-r colour to match figma * feat(ui): address PR comments * feat(ui): update ui component html * feat(ui): add copy package input component --------- Co-authored-by: MGREMY <[email protected]> * docs: add sidebar documentation * docs: add navbar documentation * Move to new angular build executor (#52) * fix: build * feat: move to new application executor * feat: config vercel * feat: update nx * fix: update vercel config * fix: add env variable in vercel config --------- Co-authored-by: GREMY Miguel <[email protected]> * Move to npm package manager (#53) * chore: move from yarn to npm * fix: vercel npm install command * fix: to npx command * chore: add trigger to workflow * fix: github ci * fix: ci commands * refactor: pretty files * Full move to NgDoc library (#55) * docs: move to ng-doc * docs: add basic config and move landing page * docs: full move to ng-doc * docs: add all getting started * docs: add customize section * docs begin components doc * chore: add lock file and move to npm ci * chore: update commands & vercel config & ci config * docs: add sidebar toggle for mobile * docs: custom theme with custom primary color * docs: add footer * docs: add page processor for demo * docs: add keyword to pages * docs: custom ng-doc generation to fit flowbite recommendations * docs: accordion docs moved to ng-doc * docs: alert docs moved to ng-doc * docs: badge docs moved to ng-doc * docs: breadcrumb docs moved to ng-doc * docs: button docs moved to ng-doc * docs: dropdown docs moved to ng-doc * docs: indicator docs moved to ng-doc * docs: modal docs moved to ng-doc * docs: navbar docs moved to ng-doc * docs: sidebar docs moved to ng-doc * docs: fix navigation bug * docs: add subtitle on pages * docs: clear file name when having demo component * docs: from angular-{ts,html} to {typescript,html} * docs: add custom header, add API page * docs: update dependencies to fix angular keywords * docs: update api generation * docs: add search bar * docs: add comments to fill the documentation * docs: add comments in service section for the documentation * docs: add documentation for pipes * docs: add comments for directives and common * fix(modal): close on route change #33 (#56) * fix(modal): close on route change #33 * fix(modal): close on backdrop click * fix(modal): use signal based viewChild instead of @ViewChild * fix(modal): set z-index to 99 * fix(modal): update ModalClass to not apply any class on the host * feat(angular): remove allowSignalWrite from component declaration * fix(sidebar): inherit color from itemgroup/menu (it not provided) (#57) * fix(sidebar): inherit color from itemgroup/menu (it not provided) * fix(sidebar): remove unnecessary computed * fix(sidebar): verify() revert back * feat: multiple changes BREAKING CHANGES: remove state service (except theme toggle) and switch from `input()` to `model()` * refacto: move flowbite.theme.service and directive input/output * refacto: remove auto call to flowbite directive and add it in template when necessary * refacto: move every @host to host elements in @component decorator * docs: remove padding x in landing page & add themeService for buttons in landing page * refacto: split common types into multiple files * chore: add public-api.ts file, preparing for segmentation with ng-packagr * docs(navbar): add navbar example with brand, dropdown and toggle (#60) * docs(navbar): add navbar example with brand and dropdown inspired by flowbite-react * docs(navbar): add example of responsive navbar * docs(navbar): fix flowbite-navbar-brand placement * docs(navbar): add description to responsive example * docs(navbar): auto close if possible * docs(docs): add base documentation * docs(docs): update parameter table & links * chore: remove BUILD-TOOLS.md * fix(docs): revert `ul` and `ol` only outside of `flowbite-dropdown` #59 (#62) fix(docs): revert `ul` and `ol` only outside of `flowbite-dropdown` * docs(sidebar): add multi-level documentation --------- Co-authored-by: MGREMY <[email protected]> Co-authored-by: Ross <[email protected]> Co-authored-by: Bence Lovász <[email protected]>
Summary by CodeRabbit
Release Notes
New Features
Improvements
Dependency Updates
Configuration Changes