Fix broken styles #3612
Merged
Fix broken styles #3612
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
📝 WalkthroughWalkthroughThis change introduces new SCSS theme and variable files, centralizes color and typography definitions, and adds imports for these resources across many component stylesheets. It refactors the banner component to use a shared height variable, and updates the switch and form components to use a typography mixin. No JavaScript or logic changes are included. Changes
Sequence Diagram(s)sequenceDiagram
participant Component SCSS
participant lime-theme.scss
participant variables.scss
participant lime-typography.scss
Component SCSS->>lime-theme.scss: @use '../../style/internal/lime-theme'
Component SCSS->>variables.scss: @use '../../style/internal/variables'
Component SCSS->>lime-typography.scss: @use '../../style/internal/lime-typography'
lime-theme.scss->>brand-colors.scss: @use '../brand-colors'
lime-theme.scss->>variables.scss: @use 'variables'
lime-theme.scss->>lime-typography.scss: @use 'lime-typography'
Possibly related PRs
Suggested labels
✨ Finishing Touches🧪 Generate unit tests
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. 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
|
There was a problem hiding this comment.
Pull Request Overview
This PR reintroduces core style modules and variables across the codebase to restore consistent theming and typography, and centralizes a banner height variable.
- Add SCSS modules for theme, typography, and shared variables to multiple component styles
- Define and export a global banner-height variable
- Configure and forward custom Material theme and typography settings
Reviewed Changes
Copilot reviewed 29 out of 29 changed files in this pull request and generated no comments.
Show a summary per file
| File | Description |
|---|---|
| src/style/internal/variables.scss | Define base style variable $lime-banner-height |
| src/style/internal/shared_input-select-picker.scss | Add theme import to shared input/select picker styles |
| src/style/internal/lime-typography.scss | Configure and forward Material typography settings |
| src/style/internal/lime-theme.scss | Set up and forward Material theme variables |
| src/style/brand-colors.scss | Introduce project-specific brand color variables |
| src/global/core-styles.scss | Include global theme styles for external use |
| src/components/tab-bar/tab-bar.scss | Import theme module for tab-bar styling |
| src/components/switch/switch.scss | Integrate theme and typography mixins in switch styles |
| src/components/spinner/spinner.scss | Add theme import to spinner styles |
| src/components/slider/slider.scss | Pull in theme styles for slider component |
| src/components/slider/partial-styles/_readonly.scss | Include theme import for slider readonly state |
| src/components/progress-flow/progress-flow.scss | Import shared variables for progress flow |
| src/components/progress-flow/progress-flow-item/progress-flow-item.scss | Add variables import to progress-flow-item |
| src/components/list/list.scss | Incorporate theme module in list styles |
| src/components/linear-progress/linear-progress.scss | Include theme import for linear-progress |
| src/components/input-field/input-field.scss | Add theme import to input-field styles |
| src/components/form/form.scss | Import theme/typography and include core-styles mixin |
| src/components/file-viewer/file-viewer.scss | Pull in shared variables for file-viewer |
| src/components/dock/dock.scss | Add shared variables import for dock component |
| src/components/dock/dock-button/dock-button.scss | Include shared variables in dock-button styles |
| src/components/dialog/dialog.scss | Import theme module for dialog styling |
| src/components/date-picker/flatpickr-adapter/flatpickr-adapter.scss | Add theme import to flatpickr adapter |
| src/components/collapsible-section/collapsible-section.scss | Integrate theme module in collapsible-section |
| src/components/circular-progress/circular-progress.scss | Include theme import in circular-progress |
| src/components/chip-set/chip-set.scss | Add theme styles to chip-set component |
| src/components/checkbox/checkbox.scss | Import theme variables for checkbox styles |
| src/components/button/button.scss | Incorporate theme module in button styling |
| src/components/banner/banner.scss | Use shared variable for banner height and import theme |
| src/components/badge/badge.scss | Pull in theme module for badge component |
Comments suppressed due to low confidence (3)
src/style/internal/lime-theme.scss:29
- [nitpick] Remove or generalize the personal note referencing 'Ads' to avoid personal attributions in shared code comments and keep documentation focused on configuration details.
// (note by Ads: they probably aren't available in MDC v11)
src/components/form/form.scss:14
- [nitpick] Add a brief comment explaining the purpose and scope of the
core-stylesmixin so it's clear what global CSS it emits and to prevent unintended side effects.
@include lime-typography.core-styles;
src/style/internal/lime-theme.scss:41
- [nitpick] Align indentation of this commented variable with the others in the block for consistent formatting and readability.
// $text-icon-on-dark: rgba(255, 255, 255, 0.5),
|
Documentation has been published to https://lundalogik.github.io/lime-elements/versions/PR-3612/ |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 13
🔭 Outside diff range comments (4)
src/components/tab-bar/tab-bar.scss (1)
7-12: Dead variables can be dropped
$tab-background-colorand$tab-separator-background-colorare declared but never referenced anywhere in the file (only$tab-separator-background-coloris referenced once, sorry$tab-background-coloronly). Removing unused variables keeps the stylesheet lean.-$tab-background-color: var(--contrast-300);src/components/checkbox/checkbox.scss (1)
10-17: Internal custom-property naming deviates from repo conventionPer our guidelines, internal implementation variables should be prefixed
--limel-<component>-…, not--lime-….
Consider renaming--lime-checkbox-unchecked-colorto--limel-checkbox-unchecked-color(and updating usages) to stay consistent across the codebase.src/components/banner/banner.scss (1)
10-65: BEM-style class names violate project guidelineSelectors like
.lime-banner__surface,.lime-banner__content, and modifiers such as.lime-banner--openfollow BEM naming. Our guidelines explicitly discourage BEM inside component shadow-DOM styles.While this predates the current change, migrating now avoids further lock-in:
-.lime-banner__surface { … } -.lime-banner__content { … } -.lime-banner--open { … } +/* e.g. */ +.surface { … } +.content { … } +:host(.open) { … }Refactor would require template updates but improves consistency and reduces CSS payload.
src/components/switch/switch.scss (1)
79-85: Redundant font declaration – can be removed
@include lime-typography.typography(body2);already setsfont-family: inherit.
A few lines further down (98-99) you set the same property manually. The second declaration is unnecessary noise.- font-family: inherit;
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (29)
src/components/badge/badge.scss(1 hunks)src/components/banner/banner.scss(2 hunks)src/components/button/button.scss(1 hunks)src/components/checkbox/checkbox.scss(1 hunks)src/components/chip-set/chip-set.scss(1 hunks)src/components/circular-progress/circular-progress.scss(1 hunks)src/components/collapsible-section/collapsible-section.scss(1 hunks)src/components/date-picker/flatpickr-adapter/flatpickr-adapter.scss(1 hunks)src/components/dialog/dialog.scss(1 hunks)src/components/dock/dock-button/dock-button.scss(1 hunks)src/components/dock/dock.scss(1 hunks)src/components/file-viewer/file-viewer.scss(1 hunks)src/components/form/form.scss(2 hunks)src/components/input-field/input-field.scss(1 hunks)src/components/linear-progress/linear-progress.scss(1 hunks)src/components/list/list.scss(1 hunks)src/components/progress-flow/progress-flow-item/progress-flow-item.scss(1 hunks)src/components/progress-flow/progress-flow.scss(1 hunks)src/components/slider/partial-styles/_readonly.scss(1 hunks)src/components/slider/slider.scss(1 hunks)src/components/spinner/spinner.scss(1 hunks)src/components/switch/switch.scss(2 hunks)src/components/tab-bar/tab-bar.scss(1 hunks)src/global/core-styles.scss(1 hunks)src/style/brand-colors.scss(1 hunks)src/style/internal/lime-theme.scss(1 hunks)src/style/internal/lime-typography.scss(1 hunks)src/style/internal/shared_input-select-picker.scss(1 hunks)src/style/internal/variables.scss(1 hunks)
🧰 Additional context used
📓 Path-based instructions (2)
src/components/**/*.scss
Instructions used from:
Sources:
📄 CodeRabbit Inference Engine
- .cursor/rules/css-class-names-in-components-using-shadow-dom.mdc
**/*.{tsx,scss}
Instructions used from:
Sources:
⚙️ CodeRabbit Configuration File
🧠 Learnings (30)
📓 Common learnings
Learnt from: CR
PR: Lundalogik/lime-elements#0
File: .cursor/rules/css-class-names-in-components-using-shadow-dom.mdc:0-0
Timestamp: 2025-07-01T14:43:04.238Z
Learning: Applies to src/components/**/*.scss : Do not use BEM-style class names in component CSS files, as components use shadow-DOM.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3567
File: src/components/ai-avatar/ai-avatar.scss:0-0
Timestamp: 2025-05-28T08:37:45.610Z
Learning: In SCSS files, CSS property values can be split across multiple lines when properly indented, particularly for complex values like animation shorthands with CSS custom properties. This is valid SCSS syntax that compiles correctly to CSS and is often the result of auto-formatting tools.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3539
File: src/components/text-editor/text-editor.scss:14-14
Timestamp: 2025-04-24T10:16:05.891Z
Learning: In SCSS, prefer using `calc()` function over native SCSS arithmetic operations (like `$variable / 2`) as it aligns with modern SASS recommendations for better CSS compatibility and interoperability with CSS variables.
src/components/slider/slider.scss (10)
Learnt from: adrianschmidt
PR: Lundalogik/lime-elements#3464
File: src/components/text-editor/prosemirror-adapter/plugins/image/inserter.ts:1-11
Timestamp: 2025-03-04T13:48:44.712Z
Learning: The lime-elements codebase must use relative imports (even with multiple "../") rather than alias imports or re-exports because they export types to `<repo-root>/dist/types`. Using non-relative imports breaks type generation as import paths from generated type files point to full .ts files rather than .d.ts files.
Learnt from: adrianschmidt
PR: Lundalogik/lime-elements#3464
File: src/components/text-editor/prosemirror-adapter/plugins/image/inserter.ts:1-11
Timestamp: 2025-03-04T14:27:29.714Z
Learning: In example components (typically found in `src/components/*/examples/`), imports of lime-elements exports should use `@limetech/lime-elements` instead of relative paths. This is because example components aren't included in type declarations and are used in documentation to show developers how to properly use lime-elements components.
Learnt from: adrianschmidt
PR: Lundalogik/lime-elements#3530
File: src/components/text-editor/examples/text-editor-composite.tsx:4-7
Timestamp: 2025-04-17T09:39:36.254Z
Learning: For lime-elements, example files should import types from the public API using '@limetech/lime-elements' rather than defining duplicate types locally. This includes types like `EditorUiType` which are part of the component's public API.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3530
File: src/components/text-editor/examples/text-editor-composite.tsx:4-7
Timestamp: 2025-04-16T14:14:18.253Z
Learning: For lime-elements, example files should be self-contained and avoid importing internal implementation details. Example files should only import public exports from '@limetech/lime-elements' or use relative imports for other files within the examples folder. Duplicating simple type definitions in example files is preferred over importing internal types.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3530
File: src/components/text-editor/examples/text-editor-composite.tsx:4-7
Timestamp: 2025-04-16T14:14:18.253Z
Learning: For lime-elements, example files should be self-contained and avoid importing internal implementation details. This includes not importing types from internal files like '../types.ts', especially those marked with @beta. Duplicating simple type definitions in example files is preferred over importing internal types that may change.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3529
File: src/components/lime-ai-avatar/lime-ai-avatar.scss:1-3
Timestamp: 2025-04-25T14:23:56.018Z
Learning: In the lime-elements repository, CSS custom properties prefixed with `--lime-` are considered internal implementation details and should not be documented in JSDoc comments, while other custom properties should be documented as they are part of the public API.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3518
File: src/components/notched-outline/examples/notched-outline-basic.scss:11-22
Timestamp: 2025-04-14T10:01:18.721Z
Learning: Examples in Lime Elements use Shadow DOM (with `shadow: true` in the component decorator) for style encapsulation, making additional class-based selectors unnecessary. This ensures styles are automatically scoped to each component without leaking to the rest of the application.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3529
File: src/components/lime-ai-avatar/lime-ai-avatar.scss:24-28
Timestamp: 2025-04-25T14:22:02.157Z
Learning: In lime-elements, CSS custom properties follow a specific naming convention:
1. Internal use variables (not for consumers) are prefixed with `--limel-component-name-`
2. External use variables (intended for consumers) are prefixed with `--component-name-`
Variables documented with JSDoc comments are typically meant for external use.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3529
File: src/components/lime-ai-avatar/lime-ai-avatar.scss:96-122
Timestamp: 2025-04-25T14:18:07.755Z
Learning: In Lime Elements components that use Shadow DOM (with `shadow: true` in the component decorator), keyframe animation names don't need to be namespaced as they are automatically scoped to the component and won't collide with animations from other components.
Learnt from: adrianschmidt
PR: Lundalogik/lime-elements#3529
File: src/components/ai-avatar/ai-avatar.scss:20-22
Timestamp: 2025-04-29T14:15:32.104Z
Learning: In components using Shadow DOM (like those in lime-elements), the universal selector `*` is already scoped to the component's shadow tree and won't cause unwanted side effects outside the component. There's no functional difference between `*` and `:host *` in this context.
src/components/slider/partial-styles/_readonly.scss (13)
Learnt from: adrianschmidt
PR: Lundalogik/lime-elements#3530
File: src/components/text-editor/examples/text-editor-composite.tsx:4-7
Timestamp: 2025-04-17T09:39:36.254Z
Learning: For lime-elements, example files should import types from the public API using '@limetech/lime-elements' rather than defining duplicate types locally. This includes types like `EditorUiType` which are part of the component's public API.
Learnt from: adrianschmidt
PR: Lundalogik/lime-elements#3464
File: src/components/text-editor/prosemirror-adapter/plugins/image/inserter.ts:1-11
Timestamp: 2025-03-04T13:48:44.712Z
Learning: The lime-elements codebase must use relative imports (even with multiple "../") rather than alias imports or re-exports because they export types to `<repo-root>/dist/types`. Using non-relative imports breaks type generation as import paths from generated type files point to full .ts files rather than .d.ts files.
Learnt from: adrianschmidt
PR: Lundalogik/lime-elements#3464
File: src/components/text-editor/prosemirror-adapter/plugins/image/inserter.ts:1-11
Timestamp: 2025-03-04T14:27:29.714Z
Learning: In example components (typically found in `src/components/*/examples/`), imports of lime-elements exports should use `@limetech/lime-elements` instead of relative paths. This is because example components aren't included in type declarations and are used in documentation to show developers how to properly use lime-elements components.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3530
File: src/components/text-editor/examples/text-editor-composite.tsx:4-7
Timestamp: 2025-04-16T14:14:18.253Z
Learning: For lime-elements, example files should be self-contained and avoid importing internal implementation details. Example files should only import public exports from '@limetech/lime-elements' or use relative imports for other files within the examples folder. Duplicating simple type definitions in example files is preferred over importing internal types.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3529
File: src/components/lime-ai-avatar/lime-ai-avatar.scss:1-3
Timestamp: 2025-04-25T14:23:56.018Z
Learning: In the lime-elements repository, CSS custom properties prefixed with `--lime-` are considered internal implementation details and should not be documented in JSDoc comments, while other custom properties should be documented as they are part of the public API.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3530
File: src/components/text-editor/examples/text-editor-composite.tsx:4-7
Timestamp: 2025-04-16T14:14:18.253Z
Learning: For lime-elements, example files should be self-contained and avoid importing internal implementation details. This includes not importing types from internal files like '../types.ts', especially those marked with @beta. Duplicating simple type definitions in example files is preferred over importing internal types that may change.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3529
File: src/components/lime-ai-avatar/lime-ai-avatar.scss:24-28
Timestamp: 2025-04-25T14:22:02.157Z
Learning: In lime-elements, CSS custom properties follow a specific naming convention:
1. Internal use variables (not for consumers) are prefixed with `--limel-component-name-`
2. External use variables (intended for consumers) are prefixed with `--component-name-`
Variables documented with JSDoc comments are typically meant for external use.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3518
File: src/components/notched-outline/examples/notched-outline-basic.scss:11-22
Timestamp: 2025-04-14T10:01:18.721Z
Learning: Examples in Lime Elements use Shadow DOM (with `shadow: true` in the component decorator) for style encapsulation, making additional class-based selectors unnecessary. This ensures styles are automatically scoped to each component without leaking to the rest of the application.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3529
File: src/components/lime-ai-avatar/lime-ai-avatar.scss:96-122
Timestamp: 2025-04-25T14:18:07.755Z
Learning: In Lime Elements components that use Shadow DOM (with `shadow: true` in the component decorator), keyframe animation names don't need to be namespaced as they are automatically scoped to the component and won't collide with animations from other components.
Learnt from: adrianschmidt
PR: Lundalogik/lime-elements#3529
File: src/components/ai-avatar/ai-avatar.scss:20-22
Timestamp: 2025-04-29T14:15:32.104Z
Learning: In components using Shadow DOM (like those in lime-elements), the universal selector `*` is already scoped to the component's shadow tree and won't cause unwanted side effects outside the component. There's no functional difference between `*` and `:host *` in this context.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3464
File: src/components/text-editor/prosemirror-adapter/plugins/image/view.scss:14-17
Timestamp: 2025-03-11T13:31:46.958Z
Learning: Lime Elements generally does not support unreasonably old browsers, so modern CSS properties like `scale` that have good support in current browsers are preferred over older alternatives.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3518
File: src/components/chip-set/chip-set.tsx:367-385
Timestamp: 2025-04-14T12:22:22.298Z
Learning: In limel-chip-set, the onClick handler should be placed on the content div (<div slot="content">) rather than on the limel-notched-outline component, and should only be applied when type is 'input'.
Learnt from: adrianschmidt
PR: Lundalogik/lime-elements#3529
File: src/components/lime-ai-avatar/lime-ai-avatar.tsx:30-38
Timestamp: 2025-04-25T13:32:56.396Z
Learning: For StencilJS components in lime-elements, prefer using the `<Host>` element to wrap child elements in the render method instead of returning an array of elements. This follows the standard pattern in the codebase and eliminates the need for key attributes.
src/components/circular-progress/circular-progress.scss (11)
Learnt from: adrianschmidt
PR: Lundalogik/lime-elements#3464
File: src/components/text-editor/prosemirror-adapter/plugins/image/inserter.ts:1-11
Timestamp: 2025-03-04T13:48:44.712Z
Learning: The lime-elements codebase must use relative imports (even with multiple "../") rather than alias imports or re-exports because they export types to `<repo-root>/dist/types`. Using non-relative imports breaks type generation as import paths from generated type files point to full .ts files rather than .d.ts files.
Learnt from: adrianschmidt
PR: Lundalogik/lime-elements#3464
File: src/components/text-editor/prosemirror-adapter/plugins/image/inserter.ts:1-11
Timestamp: 2025-03-04T14:27:29.714Z
Learning: In example components (typically found in `src/components/*/examples/`), imports of lime-elements exports should use `@limetech/lime-elements` instead of relative paths. This is because example components aren't included in type declarations and are used in documentation to show developers how to properly use lime-elements components.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3530
File: src/components/text-editor/examples/text-editor-composite.tsx:4-7
Timestamp: 2025-04-16T14:14:18.253Z
Learning: For lime-elements, example files should be self-contained and avoid importing internal implementation details. Example files should only import public exports from '@limetech/lime-elements' or use relative imports for other files within the examples folder. Duplicating simple type definitions in example files is preferred over importing internal types.
Learnt from: adrianschmidt
PR: Lundalogik/lime-elements#3530
File: src/components/text-editor/examples/text-editor-composite.tsx:4-7
Timestamp: 2025-04-17T09:39:36.254Z
Learning: For lime-elements, example files should import types from the public API using '@limetech/lime-elements' rather than defining duplicate types locally. This includes types like `EditorUiType` which are part of the component's public API.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3530
File: src/components/text-editor/examples/text-editor-composite.tsx:4-7
Timestamp: 2025-04-16T14:14:18.253Z
Learning: For lime-elements, example files should be self-contained and avoid importing internal implementation details. This includes not importing types from internal files like '../types.ts', especially those marked with @beta. Duplicating simple type definitions in example files is preferred over importing internal types that may change.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3529
File: src/components/lime-ai-avatar/lime-ai-avatar.scss:1-3
Timestamp: 2025-04-25T14:23:56.018Z
Learning: In the lime-elements repository, CSS custom properties prefixed with `--lime-` are considered internal implementation details and should not be documented in JSDoc comments, while other custom properties should be documented as they are part of the public API.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3529
File: src/components/lime-ai-avatar/lime-ai-avatar.scss:24-28
Timestamp: 2025-04-25T14:22:02.157Z
Learning: In lime-elements, CSS custom properties follow a specific naming convention:
1. Internal use variables (not for consumers) are prefixed with `--limel-component-name-`
2. External use variables (intended for consumers) are prefixed with `--component-name-`
Variables documented with JSDoc comments are typically meant for external use.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3518
File: src/components/notched-outline/examples/notched-outline-basic.scss:11-22
Timestamp: 2025-04-14T10:01:18.721Z
Learning: Examples in Lime Elements use Shadow DOM (with `shadow: true` in the component decorator) for style encapsulation, making additional class-based selectors unnecessary. This ensures styles are automatically scoped to each component without leaking to the rest of the application.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3529
File: src/components/lime-ai-avatar/lime-ai-avatar.scss:96-122
Timestamp: 2025-04-25T14:18:07.755Z
Learning: In Lime Elements components that use Shadow DOM (with `shadow: true` in the component decorator), keyframe animation names don't need to be namespaced as they are automatically scoped to the component and won't collide with animations from other components.
Learnt from: CR
PR: Lundalogik/lime-elements#0
File: .cursor/rules/css-class-names-in-components-using-shadow-dom.mdc:0-0
Timestamp: 2025-07-01T14:43:04.238Z
Learning: Applies to src/components/**/*.scss : Do not use BEM-style class names in component CSS files, as components use shadow-DOM.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3464
File: src/components/text-editor/prosemirror-adapter/plugins/image/view.scss:14-17
Timestamp: 2025-03-11T13:31:46.958Z
Learning: Lime Elements generally does not support unreasonably old browsers, so modern CSS properties like `scale` that have good support in current browsers are preferred over older alternatives.
src/components/progress-flow/progress-flow-item/progress-flow-item.scss (10)
Learnt from: CR
PR: Lundalogik/lime-elements#0
File: .cursor/rules/css-class-names-in-components-using-shadow-dom.mdc:0-0
Timestamp: 2025-07-01T14:43:04.238Z
Learning: Applies to src/components/**/*.scss : Do not use BEM-style class names in component CSS files, as components use shadow-DOM.
Learnt from: adrianschmidt
PR: Lundalogik/lime-elements#3530
File: src/components/text-editor/examples/text-editor-composite.tsx:4-7
Timestamp: 2025-04-17T09:39:36.254Z
Learning: For lime-elements, example files should import types from the public API using '@limetech/lime-elements' rather than defining duplicate types locally. This includes types like `EditorUiType` which are part of the component's public API.
Learnt from: adrianschmidt
PR: Lundalogik/lime-elements#3464
File: src/components/text-editor/prosemirror-adapter/plugins/image/inserter.ts:1-11
Timestamp: 2025-03-04T13:48:44.712Z
Learning: The lime-elements codebase must use relative imports (even with multiple "../") rather than alias imports or re-exports because they export types to `<repo-root>/dist/types`. Using non-relative imports breaks type generation as import paths from generated type files point to full .ts files rather than .d.ts files.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3529
File: src/components/lime-ai-avatar/lime-ai-avatar.scss:24-28
Timestamp: 2025-04-25T14:22:02.157Z
Learning: In lime-elements, CSS custom properties follow a specific naming convention:
1. Internal use variables (not for consumers) are prefixed with `--limel-component-name-`
2. External use variables (intended for consumers) are prefixed with `--component-name-`
Variables documented with JSDoc comments are typically meant for external use.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3529
File: src/components/lime-ai-avatar/lime-ai-avatar.scss:1-3
Timestamp: 2025-04-25T14:23:56.018Z
Learning: In the lime-elements repository, CSS custom properties prefixed with `--lime-` are considered internal implementation details and should not be documented in JSDoc comments, while other custom properties should be documented as they are part of the public API.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3539
File: src/components/text-editor/text-editor.scss:14-14
Timestamp: 2025-04-24T10:16:05.891Z
Learning: In SCSS, prefer using `calc()` function over native SCSS arithmetic operations (like `$variable / 2`) as it aligns with modern SASS recommendations for better CSS compatibility and interoperability with CSS variables.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3530
File: src/components/text-editor/examples/text-editor-composite.tsx:4-7
Timestamp: 2025-04-16T14:14:18.253Z
Learning: For lime-elements, example files should be self-contained and avoid importing internal implementation details. Example files should only import public exports from '@limetech/lime-elements' or use relative imports for other files within the examples folder. Duplicating simple type definitions in example files is preferred over importing internal types.
Learnt from: adrianschmidt
PR: Lundalogik/lime-elements#3464
File: src/components/text-editor/prosemirror-adapter/plugins/image/inserter.ts:1-11
Timestamp: 2025-03-04T14:27:29.714Z
Learning: In example components (typically found in `src/components/*/examples/`), imports of lime-elements exports should use `@limetech/lime-elements` instead of relative paths. This is because example components aren't included in type declarations and are used in documentation to show developers how to properly use lime-elements components.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3518
File: src/components/notched-outline/examples/notched-outline-basic.scss:11-22
Timestamp: 2025-04-14T10:01:18.721Z
Learning: Examples in Lime Elements use Shadow DOM (with `shadow: true` in the component decorator) for style encapsulation, making additional class-based selectors unnecessary. This ensures styles are automatically scoped to each component without leaking to the rest of the application.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3530
File: src/components/text-editor/examples/text-editor-composite.tsx:4-7
Timestamp: 2025-04-16T14:14:18.253Z
Learning: For lime-elements, example files should be self-contained and avoid importing internal implementation details. This includes not importing types from internal files like '../types.ts', especially those marked with @beta. Duplicating simple type definitions in example files is preferred over importing internal types that may change.
src/components/badge/badge.scss (11)
Learnt from: adrianschmidt
PR: Lundalogik/lime-elements#3464
File: src/components/text-editor/prosemirror-adapter/plugins/image/inserter.ts:1-11
Timestamp: 2025-03-04T13:48:44.712Z
Learning: The lime-elements codebase must use relative imports (even with multiple "../") rather than alias imports or re-exports because they export types to `<repo-root>/dist/types`. Using non-relative imports breaks type generation as import paths from generated type files point to full .ts files rather than .d.ts files.
Learnt from: adrianschmidt
PR: Lundalogik/lime-elements#3530
File: src/components/text-editor/examples/text-editor-composite.tsx:4-7
Timestamp: 2025-04-17T09:39:36.254Z
Learning: For lime-elements, example files should import types from the public API using '@limetech/lime-elements' rather than defining duplicate types locally. This includes types like `EditorUiType` which are part of the component's public API.
Learnt from: adrianschmidt
PR: Lundalogik/lime-elements#3464
File: src/components/text-editor/prosemirror-adapter/plugins/image/inserter.ts:1-11
Timestamp: 2025-03-04T14:27:29.714Z
Learning: In example components (typically found in `src/components/*/examples/`), imports of lime-elements exports should use `@limetech/lime-elements` instead of relative paths. This is because example components aren't included in type declarations and are used in documentation to show developers how to properly use lime-elements components.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3530
File: src/components/text-editor/examples/text-editor-composite.tsx:4-7
Timestamp: 2025-04-16T14:14:18.253Z
Learning: For lime-elements, example files should be self-contained and avoid importing internal implementation details. Example files should only import public exports from '@limetech/lime-elements' or use relative imports for other files within the examples folder. Duplicating simple type definitions in example files is preferred over importing internal types.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3530
File: src/components/text-editor/examples/text-editor-composite.tsx:4-7
Timestamp: 2025-04-16T14:14:18.253Z
Learning: For lime-elements, example files should be self-contained and avoid importing internal implementation details. This includes not importing types from internal files like '../types.ts', especially those marked with @beta. Duplicating simple type definitions in example files is preferred over importing internal types that may change.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3518
File: src/components/notched-outline/examples/notched-outline-basic.scss:11-22
Timestamp: 2025-04-14T10:01:18.721Z
Learning: Examples in Lime Elements use Shadow DOM (with `shadow: true` in the component decorator) for style encapsulation, making additional class-based selectors unnecessary. This ensures styles are automatically scoped to each component without leaking to the rest of the application.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3529
File: src/components/lime-ai-avatar/lime-ai-avatar.scss:1-3
Timestamp: 2025-04-25T14:23:56.018Z
Learning: In the lime-elements repository, CSS custom properties prefixed with `--lime-` are considered internal implementation details and should not be documented in JSDoc comments, while other custom properties should be documented as they are part of the public API.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3529
File: src/components/lime-ai-avatar/lime-ai-avatar.scss:24-28
Timestamp: 2025-04-25T14:22:02.157Z
Learning: In lime-elements, CSS custom properties follow a specific naming convention:
1. Internal use variables (not for consumers) are prefixed with `--limel-component-name-`
2. External use variables (intended for consumers) are prefixed with `--component-name-`
Variables documented with JSDoc comments are typically meant for external use.
Learnt from: CR
PR: Lundalogik/lime-elements#0
File: .cursor/rules/css-class-names-in-components-using-shadow-dom.mdc:0-0
Timestamp: 2025-07-01T14:43:04.238Z
Learning: Applies to src/components/**/*.scss : Do not use BEM-style class names in component CSS files, as components use shadow-DOM.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3529
File: src/components/lime-ai-avatar/lime-ai-avatar.scss:96-122
Timestamp: 2025-04-25T14:18:07.755Z
Learning: In Lime Elements components that use Shadow DOM (with `shadow: true` in the component decorator), keyframe animation names don't need to be namespaced as they are automatically scoped to the component and won't collide with animations from other components.
Learnt from: adrianschmidt
PR: Lundalogik/lime-elements#3529
File: src/components/ai-avatar/ai-avatar.scss:20-22
Timestamp: 2025-04-29T14:15:32.104Z
Learning: In components using Shadow DOM (like those in lime-elements), the universal selector `*` is already scoped to the component's shadow tree and won't cause unwanted side effects outside the component. There's no functional difference between `*` and `:host *` in this context.
src/components/linear-progress/linear-progress.scss (10)
Learnt from: adrianschmidt
PR: Lundalogik/lime-elements#3464
File: src/components/text-editor/prosemirror-adapter/plugins/image/inserter.ts:1-11
Timestamp: 2025-03-04T13:48:44.712Z
Learning: The lime-elements codebase must use relative imports (even with multiple "../") rather than alias imports or re-exports because they export types to `<repo-root>/dist/types`. Using non-relative imports breaks type generation as import paths from generated type files point to full .ts files rather than .d.ts files.
Learnt from: adrianschmidt
PR: Lundalogik/lime-elements#3464
File: src/components/text-editor/prosemirror-adapter/plugins/image/inserter.ts:1-11
Timestamp: 2025-03-04T14:27:29.714Z
Learning: In example components (typically found in `src/components/*/examples/`), imports of lime-elements exports should use `@limetech/lime-elements` instead of relative paths. This is because example components aren't included in type declarations and are used in documentation to show developers how to properly use lime-elements components.
Learnt from: adrianschmidt
PR: Lundalogik/lime-elements#3530
File: src/components/text-editor/examples/text-editor-composite.tsx:4-7
Timestamp: 2025-04-17T09:39:36.254Z
Learning: For lime-elements, example files should import types from the public API using '@limetech/lime-elements' rather than defining duplicate types locally. This includes types like `EditorUiType` which are part of the component's public API.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3530
File: src/components/text-editor/examples/text-editor-composite.tsx:4-7
Timestamp: 2025-04-16T14:14:18.253Z
Learning: For lime-elements, example files should be self-contained and avoid importing internal implementation details. Example files should only import public exports from '@limetech/lime-elements' or use relative imports for other files within the examples folder. Duplicating simple type definitions in example files is preferred over importing internal types.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3530
File: src/components/text-editor/examples/text-editor-composite.tsx:4-7
Timestamp: 2025-04-16T14:14:18.253Z
Learning: For lime-elements, example files should be self-contained and avoid importing internal implementation details. This includes not importing types from internal files like '../types.ts', especially those marked with @beta. Duplicating simple type definitions in example files is preferred over importing internal types that may change.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3529
File: src/components/lime-ai-avatar/lime-ai-avatar.scss:1-3
Timestamp: 2025-04-25T14:23:56.018Z
Learning: In the lime-elements repository, CSS custom properties prefixed with `--lime-` are considered internal implementation details and should not be documented in JSDoc comments, while other custom properties should be documented as they are part of the public API.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3529
File: src/components/lime-ai-avatar/lime-ai-avatar.scss:24-28
Timestamp: 2025-04-25T14:22:02.157Z
Learning: In lime-elements, CSS custom properties follow a specific naming convention:
1. Internal use variables (not for consumers) are prefixed with `--limel-component-name-`
2. External use variables (intended for consumers) are prefixed with `--component-name-`
Variables documented with JSDoc comments are typically meant for external use.
Learnt from: CR
PR: Lundalogik/lime-elements#0
File: .cursor/rules/css-class-names-in-components-using-shadow-dom.mdc:0-0
Timestamp: 2025-07-01T14:43:04.238Z
Learning: Applies to src/components/**/*.scss : Do not use BEM-style class names in component CSS files, as components use shadow-DOM.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3518
File: src/components/notched-outline/examples/notched-outline-basic.scss:11-22
Timestamp: 2025-04-14T10:01:18.721Z
Learning: Examples in Lime Elements use Shadow DOM (with `shadow: true` in the component decorator) for style encapsulation, making additional class-based selectors unnecessary. This ensures styles are automatically scoped to each component without leaking to the rest of the application.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3529
File: src/components/lime-ai-avatar/lime-ai-avatar.scss:96-122
Timestamp: 2025-04-25T14:18:07.755Z
Learning: In Lime Elements components that use Shadow DOM (with `shadow: true` in the component decorator), keyframe animation names don't need to be namespaced as they are automatically scoped to the component and won't collide with animations from other components.
src/components/chip-set/chip-set.scss (12)
Learnt from: adrianschmidt
PR: Lundalogik/lime-elements#3530
File: src/components/text-editor/examples/text-editor-composite.tsx:4-7
Timestamp: 2025-04-17T09:39:36.254Z
Learning: For lime-elements, example files should import types from the public API using '@limetech/lime-elements' rather than defining duplicate types locally. This includes types like `EditorUiType` which are part of the component's public API.
Learnt from: adrianschmidt
PR: Lundalogik/lime-elements#3464
File: src/components/text-editor/prosemirror-adapter/plugins/image/inserter.ts:1-11
Timestamp: 2025-03-04T14:27:29.714Z
Learning: In example components (typically found in `src/components/*/examples/`), imports of lime-elements exports should use `@limetech/lime-elements` instead of relative paths. This is because example components aren't included in type declarations and are used in documentation to show developers how to properly use lime-elements components.
Learnt from: adrianschmidt
PR: Lundalogik/lime-elements#3464
File: src/components/text-editor/prosemirror-adapter/plugins/image/inserter.ts:1-11
Timestamp: 2025-03-04T13:48:44.712Z
Learning: The lime-elements codebase must use relative imports (even with multiple "../") rather than alias imports or re-exports because they export types to `<repo-root>/dist/types`. Using non-relative imports breaks type generation as import paths from generated type files point to full .ts files rather than .d.ts files.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3530
File: src/components/text-editor/examples/text-editor-composite.tsx:4-7
Timestamp: 2025-04-16T14:14:18.253Z
Learning: For lime-elements, example files should be self-contained and avoid importing internal implementation details. Example files should only import public exports from '@limetech/lime-elements' or use relative imports for other files within the examples folder. Duplicating simple type definitions in example files is preferred over importing internal types.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3530
File: src/components/text-editor/examples/text-editor-composite.tsx:4-7
Timestamp: 2025-04-16T14:14:18.253Z
Learning: For lime-elements, example files should be self-contained and avoid importing internal implementation details. This includes not importing types from internal files like '../types.ts', especially those marked with @beta. Duplicating simple type definitions in example files is preferred over importing internal types that may change.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3529
File: src/components/lime-ai-avatar/lime-ai-avatar.scss:1-3
Timestamp: 2025-04-25T14:23:56.018Z
Learning: In the lime-elements repository, CSS custom properties prefixed with `--lime-` are considered internal implementation details and should not be documented in JSDoc comments, while other custom properties should be documented as they are part of the public API.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3529
File: src/components/lime-ai-avatar/lime-ai-avatar.scss:24-28
Timestamp: 2025-04-25T14:22:02.157Z
Learning: In lime-elements, CSS custom properties follow a specific naming convention:
1. Internal use variables (not for consumers) are prefixed with `--limel-component-name-`
2. External use variables (intended for consumers) are prefixed with `--component-name-`
Variables documented with JSDoc comments are typically meant for external use.
Learnt from: CR
PR: Lundalogik/lime-elements#0
File: .cursor/rules/css-class-names-in-components-using-shadow-dom.mdc:0-0
Timestamp: 2025-07-01T14:43:04.238Z
Learning: Applies to src/components/**/*.scss : Do not use BEM-style class names in component CSS files, as components use shadow-DOM.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3518
File: src/components/notched-outline/examples/notched-outline-basic.scss:11-22
Timestamp: 2025-04-14T10:01:18.721Z
Learning: Examples in Lime Elements use Shadow DOM (with `shadow: true` in the component decorator) for style encapsulation, making additional class-based selectors unnecessary. This ensures styles are automatically scoped to each component without leaking to the rest of the application.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3529
File: src/components/lime-ai-avatar/lime-ai-avatar.scss:96-122
Timestamp: 2025-04-25T14:18:07.755Z
Learning: In Lime Elements components that use Shadow DOM (with `shadow: true` in the component decorator), keyframe animation names don't need to be namespaced as they are automatically scoped to the component and won't collide with animations from other components.
Learnt from: adrianschmidt
PR: Lundalogik/lime-elements#3529
File: src/components/ai-avatar/ai-avatar.scss:20-22
Timestamp: 2025-04-29T14:15:32.104Z
Learning: In components using Shadow DOM (like those in lime-elements), the universal selector `*` is already scoped to the component's shadow tree and won't cause unwanted side effects outside the component. There's no functional difference between `*` and `:host *` in this context.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3518
File: src/components/chip-set/chip-set.tsx:367-385
Timestamp: 2025-04-14T12:22:22.298Z
Learning: In limel-chip-set, the onClick handler should be placed on the content div (<div slot="content">) rather than on the limel-notched-outline component, and should only be applied when type is 'input'.
src/components/collapsible-section/collapsible-section.scss (11)
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3530
File: src/components/text-editor/examples/text-editor-composite.tsx:4-7
Timestamp: 2025-04-16T14:14:18.253Z
Learning: For lime-elements, example files should be self-contained and avoid importing internal implementation details. Example files should only import public exports from '@limetech/lime-elements' or use relative imports for other files within the examples folder. Duplicating simple type definitions in example files is preferred over importing internal types.
Learnt from: adrianschmidt
PR: Lundalogik/lime-elements#3530
File: src/components/text-editor/examples/text-editor-composite.tsx:4-7
Timestamp: 2025-04-17T09:39:36.254Z
Learning: For lime-elements, example files should import types from the public API using '@limetech/lime-elements' rather than defining duplicate types locally. This includes types like `EditorUiType` which are part of the component's public API.
Learnt from: adrianschmidt
PR: Lundalogik/lime-elements#3464
File: src/components/text-editor/prosemirror-adapter/plugins/image/inserter.ts:1-11
Timestamp: 2025-03-04T14:27:29.714Z
Learning: In example components (typically found in `src/components/*/examples/`), imports of lime-elements exports should use `@limetech/lime-elements` instead of relative paths. This is because example components aren't included in type declarations and are used in documentation to show developers how to properly use lime-elements components.
Learnt from: adrianschmidt
PR: Lundalogik/lime-elements#3464
File: src/components/text-editor/prosemirror-adapter/plugins/image/inserter.ts:1-11
Timestamp: 2025-03-04T13:48:44.712Z
Learning: The lime-elements codebase must use relative imports (even with multiple "../") rather than alias imports or re-exports because they export types to `<repo-root>/dist/types`. Using non-relative imports breaks type generation as import paths from generated type files point to full .ts files rather than .d.ts files.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3518
File: src/components/notched-outline/examples/notched-outline-basic.scss:11-22
Timestamp: 2025-04-14T10:01:18.721Z
Learning: Examples in Lime Elements use Shadow DOM (with `shadow: true` in the component decorator) for style encapsulation, making additional class-based selectors unnecessary. This ensures styles are automatically scoped to each component without leaking to the rest of the application.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3529
File: src/components/lime-ai-avatar/lime-ai-avatar.scss:1-3
Timestamp: 2025-04-25T14:23:56.018Z
Learning: In the lime-elements repository, CSS custom properties prefixed with `--lime-` are considered internal implementation details and should not be documented in JSDoc comments, while other custom properties should be documented as they are part of the public API.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3530
File: src/components/text-editor/examples/text-editor-composite.tsx:4-7
Timestamp: 2025-04-16T14:14:18.253Z
Learning: For lime-elements, example files should be self-contained and avoid importing internal implementation details. This includes not importing types from internal files like '../types.ts', especially those marked with @beta. Duplicating simple type definitions in example files is preferred over importing internal types that may change.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3529
File: src/components/lime-ai-avatar/lime-ai-avatar.scss:24-28
Timestamp: 2025-04-25T14:22:02.157Z
Learning: In lime-elements, CSS custom properties follow a specific naming convention:
1. Internal use variables (not for consumers) are prefixed with `--limel-component-name-`
2. External use variables (intended for consumers) are prefixed with `--component-name-`
Variables documented with JSDoc comments are typically meant for external use.
Learnt from: CR
PR: Lundalogik/lime-elements#0
File: .cursor/rules/css-class-names-in-components-using-shadow-dom.mdc:0-0
Timestamp: 2025-07-01T14:43:04.238Z
Learning: Applies to src/components/**/*.scss : Do not use BEM-style class names in component CSS files, as components use shadow-DOM.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3529
File: src/components/lime-ai-avatar/lime-ai-avatar.scss:96-122
Timestamp: 2025-04-25T14:18:07.755Z
Learning: In Lime Elements components that use Shadow DOM (with `shadow: true` in the component decorator), keyframe animation names don't need to be namespaced as they are automatically scoped to the component and won't collide with animations from other components.
Learnt from: adrianschmidt
PR: Lundalogik/lime-elements#3529
File: src/components/ai-avatar/ai-avatar.scss:20-22
Timestamp: 2025-04-29T14:15:32.104Z
Learning: In components using Shadow DOM (like those in lime-elements), the universal selector `*` is already scoped to the component's shadow tree and won't cause unwanted side effects outside the component. There's no functional difference between `*` and `:host *` in this context.
src/components/list/list.scss (11)
Learnt from: adrianschmidt
PR: Lundalogik/lime-elements#3530
File: src/components/text-editor/examples/text-editor-composite.tsx:4-7
Timestamp: 2025-04-17T09:39:36.254Z
Learning: For lime-elements, example files should import types from the public API using '@limetech/lime-elements' rather than defining duplicate types locally. This includes types like `EditorUiType` which are part of the component's public API.
Learnt from: adrianschmidt
PR: Lundalogik/lime-elements#3464
File: src/components/text-editor/prosemirror-adapter/plugins/image/inserter.ts:1-11
Timestamp: 2025-03-04T14:27:29.714Z
Learning: In example components (typically found in `src/components/*/examples/`), imports of lime-elements exports should use `@limetech/lime-elements` instead of relative paths. This is because example components aren't included in type declarations and are used in documentation to show developers how to properly use lime-elements components.
Learnt from: adrianschmidt
PR: Lundalogik/lime-elements#3464
File: src/components/text-editor/prosemirror-adapter/plugins/image/inserter.ts:1-11
Timestamp: 2025-03-04T13:48:44.712Z
Learning: The lime-elements codebase must use relative imports (even with multiple "../") rather than alias imports or re-exports because they export types to `<repo-root>/dist/types`. Using non-relative imports breaks type generation as import paths from generated type files point to full .ts files rather than .d.ts files.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3530
File: src/components/text-editor/examples/text-editor-composite.tsx:4-7
Timestamp: 2025-04-16T14:14:18.253Z
Learning: For lime-elements, example files should be self-contained and avoid importing internal implementation details. Example files should only import public exports from '@limetech/lime-elements' or use relative imports for other files within the examples folder. Duplicating simple type definitions in example files is preferred over importing internal types.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3530
File: src/components/text-editor/examples/text-editor-composite.tsx:4-7
Timestamp: 2025-04-16T14:14:18.253Z
Learning: For lime-elements, example files should be self-contained and avoid importing internal implementation details. This includes not importing types from internal files like '../types.ts', especially those marked with @beta. Duplicating simple type definitions in example files is preferred over importing internal types that may change.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3529
File: src/components/lime-ai-avatar/lime-ai-avatar.scss:1-3
Timestamp: 2025-04-25T14:23:56.018Z
Learning: In the lime-elements repository, CSS custom properties prefixed with `--lime-` are considered internal implementation details and should not be documented in JSDoc comments, while other custom properties should be documented as they are part of the public API.
Learnt from: CR
PR: Lundalogik/lime-elements#0
File: .cursor/rules/css-class-names-in-components-using-shadow-dom.mdc:0-0
Timestamp: 2025-07-01T14:43:04.238Z
Learning: Applies to src/components/**/*.scss : Do not use BEM-style class names in component CSS files, as components use shadow-DOM.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3529
File: src/components/lime-ai-avatar/lime-ai-avatar.scss:24-28
Timestamp: 2025-04-25T14:22:02.157Z
Learning: In lime-elements, CSS custom properties follow a specific naming convention:
1. Internal use variables (not for consumers) are prefixed with `--limel-component-name-`
2. External use variables (intended for consumers) are prefixed with `--component-name-`
Variables documented with JSDoc comments are typically meant for external use.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3518
File: src/components/notched-outline/examples/notched-outline-basic.scss:11-22
Timestamp: 2025-04-14T10:01:18.721Z
Learning: Examples in Lime Elements use Shadow DOM (with `shadow: true` in the component decorator) for style encapsulation, making additional class-based selectors unnecessary. This ensures styles are automatically scoped to each component without leaking to the rest of the application.
Learnt from: adrianschmidt
PR: Lundalogik/lime-elements#3529
File: src/components/ai-avatar/ai-avatar.scss:20-22
Timestamp: 2025-04-29T14:15:32.104Z
Learning: In components using Shadow DOM (like those in lime-elements), the universal selector `*` is already scoped to the component's shadow tree and won't cause unwanted side effects outside the component. There's no functional difference between `*` and `:host *` in this context.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3529
File: src/components/lime-ai-avatar/lime-ai-avatar.scss:96-122
Timestamp: 2025-04-25T14:18:07.755Z
Learning: In Lime Elements components that use Shadow DOM (with `shadow: true` in the component decorator), keyframe animation names don't need to be namespaced as they are automatically scoped to the component and won't collide with animations from other components.
src/components/spinner/spinner.scss (11)
Learnt from: adrianschmidt
PR: Lundalogik/lime-elements#3464
File: src/components/text-editor/prosemirror-adapter/plugins/image/inserter.ts:1-11
Timestamp: 2025-03-04T13:48:44.712Z
Learning: The lime-elements codebase must use relative imports (even with multiple "../") rather than alias imports or re-exports because they export types to `<repo-root>/dist/types`. Using non-relative imports breaks type generation as import paths from generated type files point to full .ts files rather than .d.ts files.
Learnt from: adrianschmidt
PR: Lundalogik/lime-elements#3464
File: src/components/text-editor/prosemirror-adapter/plugins/image/inserter.ts:1-11
Timestamp: 2025-03-04T14:27:29.714Z
Learning: In example components (typically found in `src/components/*/examples/`), imports of lime-elements exports should use `@limetech/lime-elements` instead of relative paths. This is because example components aren't included in type declarations and are used in documentation to show developers how to properly use lime-elements components.
Learnt from: adrianschmidt
PR: Lundalogik/lime-elements#3530
File: src/components/text-editor/examples/text-editor-composite.tsx:4-7
Timestamp: 2025-04-17T09:39:36.254Z
Learning: For lime-elements, example files should import types from the public API using '@limetech/lime-elements' rather than defining duplicate types locally. This includes types like `EditorUiType` which are part of the component's public API.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3530
File: src/components/text-editor/examples/text-editor-composite.tsx:4-7
Timestamp: 2025-04-16T14:14:18.253Z
Learning: For lime-elements, example files should be self-contained and avoid importing internal implementation details. Example files should only import public exports from '@limetech/lime-elements' or use relative imports for other files within the examples folder. Duplicating simple type definitions in example files is preferred over importing internal types.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3530
File: src/components/text-editor/examples/text-editor-composite.tsx:4-7
Timestamp: 2025-04-16T14:14:18.253Z
Learning: For lime-elements, example files should be self-contained and avoid importing internal implementation details. This includes not importing types from internal files like '../types.ts', especially those marked with @beta. Duplicating simple type definitions in example files is preferred over importing internal types that may change.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3518
File: src/components/notched-outline/examples/notched-outline-basic.scss:11-22
Timestamp: 2025-04-14T10:01:18.721Z
Learning: Examples in Lime Elements use Shadow DOM (with `shadow: true` in the component decorator) for style encapsulation, making additional class-based selectors unnecessary. This ensures styles are automatically scoped to each component without leaking to the rest of the application.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3529
File: src/components/lime-ai-avatar/lime-ai-avatar.scss:1-3
Timestamp: 2025-04-25T14:23:56.018Z
Learning: In the lime-elements repository, CSS custom properties prefixed with `--lime-` are considered internal implementation details and should not be documented in JSDoc comments, while other custom properties should be documented as they are part of the public API.
Learnt from: CR
PR: Lundalogik/lime-elements#0
File: .cursor/rules/css-class-names-in-components-using-shadow-dom.mdc:0-0
Timestamp: 2025-07-01T14:43:04.238Z
Learning: Applies to src/components/**/*.scss : Do not use BEM-style class names in component CSS files, as components use shadow-DOM.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3529
File: src/components/lime-ai-avatar/lime-ai-avatar.scss:24-28
Timestamp: 2025-04-25T14:22:02.157Z
Learning: In lime-elements, CSS custom properties follow a specific naming convention:
1. Internal use variables (not for consumers) are prefixed with `--limel-component-name-`
2. External use variables (intended for consumers) are prefixed with `--component-name-`
Variables documented with JSDoc comments are typically meant for external use.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3529
File: src/components/lime-ai-avatar/lime-ai-avatar.scss:96-122
Timestamp: 2025-04-25T14:18:07.755Z
Learning: In Lime Elements components that use Shadow DOM (with `shadow: true` in the component decorator), keyframe animation names don't need to be namespaced as they are automatically scoped to the component and won't collide with animations from other components.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3539
File: src/components/text-editor/text-editor.scss:14-14
Timestamp: 2025-04-24T10:16:05.891Z
Learning: In SCSS, prefer using `calc()` function over native SCSS arithmetic operations (like `$variable / 2`) as it aligns with modern SASS recommendations for better CSS compatibility and interoperability with CSS variables.
src/components/tab-bar/tab-bar.scss (11)
Learnt from: adrianschmidt
PR: Lundalogik/lime-elements#3464
File: src/components/text-editor/prosemirror-adapter/plugins/image/inserter.ts:1-11
Timestamp: 2025-03-04T13:48:44.712Z
Learning: The lime-elements codebase must use relative imports (even with multiple "../") rather than alias imports or re-exports because they export types to `<repo-root>/dist/types`. Using non-relative imports breaks type generation as import paths from generated type files point to full .ts files rather than .d.ts files.
Learnt from: adrianschmidt
PR: Lundalogik/lime-elements#3530
File: src/components/text-editor/examples/text-editor-composite.tsx:4-7
Timestamp: 2025-04-17T09:39:36.254Z
Learning: For lime-elements, example files should import types from the public API using '@limetech/lime-elements' rather than defining duplicate types locally. This includes types like `EditorUiType` which are part of the component's public API.
Learnt from: adrianschmidt
PR: Lundalogik/lime-elements#3464
File: src/components/text-editor/prosemirror-adapter/plugins/image/inserter.ts:1-11
Timestamp: 2025-03-04T14:27:29.714Z
Learning: In example components (typically found in `src/components/*/examples/`), imports of lime-elements exports should use `@limetech/lime-elements` instead of relative paths. This is because example components aren't included in type declarations and are used in documentation to show developers how to properly use lime-elements components.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3530
File: src/components/text-editor/examples/text-editor-composite.tsx:4-7
Timestamp: 2025-04-16T14:14:18.253Z
Learning: For lime-elements, example files should be self-contained and avoid importing internal implementation details. Example files should only import public exports from '@limetech/lime-elements' or use relative imports for other files within the examples folder. Duplicating simple type definitions in example files is preferred over importing internal types.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3530
File: src/components/text-editor/examples/text-editor-composite.tsx:4-7
Timestamp: 2025-04-16T14:14:18.253Z
Learning: For lime-elements, example files should be self-contained and avoid importing internal implementation details. This includes not importing types from internal files like '../types.ts', especially those marked with @beta. Duplicating simple type definitions in example files is preferred over importing internal types that may change.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3529
File: src/components/lime-ai-avatar/lime-ai-avatar.scss:1-3
Timestamp: 2025-04-25T14:23:56.018Z
Learning: In the lime-elements repository, CSS custom properties prefixed with `--lime-` are considered internal implementation details and should not be documented in JSDoc comments, while other custom properties should be documented as they are part of the public API.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3529
File: src/components/lime-ai-avatar/lime-ai-avatar.scss:24-28
Timestamp: 2025-04-25T14:22:02.157Z
Learning: In lime-elements, CSS custom properties follow a specific naming convention:
1. Internal use variables (not for consumers) are prefixed with `--limel-component-name-`
2. External use variables (intended for consumers) are prefixed with `--component-name-`
Variables documented with JSDoc comments are typically meant for external use.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3518
File: src/components/notched-outline/examples/notched-outline-basic.scss:11-22
Timestamp: 2025-04-14T10:01:18.721Z
Learning: Examples in Lime Elements use Shadow DOM (with `shadow: true` in the component decorator) for style encapsulation, making additional class-based selectors unnecessary. This ensures styles are automatically scoped to each component without leaking to the rest of the application.
Learnt from: CR
PR: Lundalogik/lime-elements#0
File: .cursor/rules/css-class-names-in-components-using-shadow-dom.mdc:0-0
Timestamp: 2025-07-01T14:43:04.238Z
Learning: Applies to src/components/**/*.scss : Do not use BEM-style class names in component CSS files, as components use shadow-DOM.
Learnt from: adrianschmidt
PR: Lundalogik/lime-elements#3529
File: src/components/ai-avatar/ai-avatar.scss:20-22
Timestamp: 2025-04-29T14:15:32.104Z
Learning: In components using Shadow DOM (like those in lime-elements), the universal selector `*` is already scoped to the component's shadow tree and won't cause unwanted side effects outside the component. There's no functional difference between `*` and `:host *` in this context.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3529
File: src/components/lime-ai-avatar/lime-ai-avatar.scss:96-122
Timestamp: 2025-04-25T14:18:07.755Z
Learning: In Lime Elements components that use Shadow DOM (with `shadow: true` in the component decorator), keyframe animation names don't need to be namespaced as they are automatically scoped to the component and won't collide with animations from other components.
src/components/dialog/dialog.scss (11)
Learnt from: adrianschmidt
PR: Lundalogik/lime-elements#3530
File: src/components/text-editor/examples/text-editor-composite.tsx:4-7
Timestamp: 2025-04-17T09:39:36.254Z
Learning: For lime-elements, example files should import types from the public API using '@limetech/lime-elements' rather than defining duplicate types locally. This includes types like `EditorUiType` which are part of the component's public API.
Learnt from: adrianschmidt
PR: Lundalogik/lime-elements#3464
File: src/components/text-editor/prosemirror-adapter/plugins/image/inserter.ts:1-11
Timestamp: 2025-03-04T14:27:29.714Z
Learning: In example components (typically found in `src/components/*/examples/`), imports of lime-elements exports should use `@limetech/lime-elements` instead of relative paths. This is because example components aren't included in type declarations and are used in documentation to show developers how to properly use lime-elements components.
Learnt from: adrianschmidt
PR: Lundalogik/lime-elements#3464
File: src/components/text-editor/prosemirror-adapter/plugins/image/inserter.ts:1-11
Timestamp: 2025-03-04T13:48:44.712Z
Learning: The lime-elements codebase must use relative imports (even with multiple "../") rather than alias imports or re-exports because they export types to `<repo-root>/dist/types`. Using non-relative imports breaks type generation as import paths from generated type files point to full .ts files rather than .d.ts files.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3530
File: src/components/text-editor/examples/text-editor-composite.tsx:4-7
Timestamp: 2025-04-16T14:14:18.253Z
Learning: For lime-elements, example files should be self-contained and avoid importing internal implementation details. Example files should only import public exports from '@limetech/lime-elements' or use relative imports for other files within the examples folder. Duplicating simple type definitions in example files is preferred over importing internal types.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3530
File: src/components/text-editor/examples/text-editor-composite.tsx:4-7
Timestamp: 2025-04-16T14:14:18.253Z
Learning: For lime-elements, example files should be self-contained and avoid importing internal implementation details. This includes not importing types from internal files like '../types.ts', especially those marked with @beta. Duplicating simple type definitions in example files is preferred over importing internal types that may change.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3529
File: src/components/lime-ai-avatar/lime-ai-avatar.scss:1-3
Timestamp: 2025-04-25T14:23:56.018Z
Learning: In the lime-elements repository, CSS custom properties prefixed with `--lime-` are considered internal implementation details and should not be documented in JSDoc comments, while other custom properties should be documented as they are part of the public API.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3518
File: src/components/notched-outline/examples/notched-outline-basic.scss:11-22
Timestamp: 2025-04-14T10:01:18.721Z
Learning: Examples in Lime Elements use Shadow DOM (with `shadow: true` in the component decorator) for style encapsulation, making additional class-based selectors unnecessary. This ensures styles are automatically scoped to each component without leaking to the rest of the application.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3529
File: src/components/lime-ai-avatar/lime-ai-avatar.scss:24-28
Timestamp: 2025-04-25T14:22:02.157Z
Learning: In lime-elements, CSS custom properties follow a specific naming convention:
1. Internal use variables (not for consumers) are prefixed with `--limel-component-name-`
2. External use variables (intended for consumers) are prefixed with `--component-name-`
Variables documented with JSDoc comments are typically meant for external use.
Learnt from: CR
PR: Lundalogik/lime-elements#0
File: .cursor/rules/css-class-names-in-components-using-shadow-dom.mdc:0-0
Timestamp: 2025-07-01T14:43:04.238Z
Learning: Applies to src/components/**/*.scss : Do not use BEM-style class names in component CSS files, as components use shadow-DOM.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3529
File: src/components/lime-ai-avatar/lime-ai-avatar.scss:96-122
Timestamp: 2025-04-25T14:18:07.755Z
Learning: In Lime Elements components that use Shadow DOM (with `shadow: true` in the component decorator), keyframe animation names don't need to be namespaced as they are automatically scoped to the component and won't collide with animations from other components.
Learnt from: adrianschmidt
PR: Lundalogik/lime-elements#3529
File: src/components/ai-avatar/ai-avatar.scss:20-22
Timestamp: 2025-04-29T14:15:32.104Z
Learning: In components using Shadow DOM (like those in lime-elements), the universal selector `*` is already scoped to the component's shadow tree and won't cause unwanted side effects outside the component. There's no functional difference between `*` and `:host *` in this context.
src/components/dock/dock-button/dock-button.scss (4)
Learnt from: CR
PR: Lundalogik/lime-elements#0
File: .cursor/rules/css-class-names-in-components-using-shadow-dom.mdc:0-0
Timestamp: 2025-07-01T14:43:04.238Z
Learning: Applies to src/components/**/*.scss : Do not use BEM-style class names in component CSS files, as components use shadow-DOM.
Learnt from: adrianschmidt
PR: Lundalogik/lime-elements#3530
File: src/components/text-editor/examples/text-editor-composite.tsx:4-7
Timestamp: 2025-04-17T09:39:36.254Z
Learning: For lime-elements, example files should import types from the public API using '@limetech/lime-elements' rather than defining duplicate types locally. This includes types like `EditorUiType` which are part of the component's public API.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3529
File: src/components/lime-ai-avatar/lime-ai-avatar.scss:24-28
Timestamp: 2025-04-25T14:22:02.157Z
Learning: In lime-elements, CSS custom properties follow a specific naming convention:
1. Internal use variables (not for consumers) are prefixed with `--limel-component-name-`
2. External use variables (intended for consumers) are prefixed with `--component-name-`
Variables documented with JSDoc comments are typically meant for external use.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3539
File: src/components/text-editor/text-editor.scss:14-14
Timestamp: 2025-04-24T10:16:05.891Z
Learning: In SCSS, prefer using `calc()` function over native SCSS arithmetic operations (like `$variable / 2`) as it aligns with modern SASS recommendations for better CSS compatibility and interoperability with CSS variables.
src/components/date-picker/flatpickr-adapter/flatpickr-adapter.scss (10)
Learnt from: adrianschmidt
PR: Lundalogik/lime-elements#3530
File: src/components/text-editor/examples/text-editor-composite.tsx:4-7
Timestamp: 2025-04-17T09:39:36.254Z
Learning: For lime-elements, example files should import types from the public API using '@limetech/lime-elements' rather than defining duplicate types locally. This includes types like `EditorUiType` which are part of the component's public API.
Learnt from: adrianschmidt
PR: Lundalogik/lime-elements#3464
File: src/components/text-editor/prosemirror-adapter/plugins/image/inserter.ts:1-11
Timestamp: 2025-03-04T13:48:44.712Z
Learning: The lime-elements codebase must use relative imports (even with multiple "../") rather than alias imports or re-exports because they export types to `<repo-root>/dist/types`. Using non-relative imports breaks type generation as import paths from generated type files point to full .ts files rather than .d.ts files.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3530
File: src/components/text-editor/examples/text-editor-composite.tsx:4-7
Timestamp: 2025-04-16T14:14:18.253Z
Learning: For lime-elements, example files should be self-contained and avoid importing internal implementation details. Example files should only import public exports from '@limetech/lime-elements' or use relative imports for other files within the examples folder. Duplicating simple type definitions in example files is preferred over importing internal types.
Learnt from: adrianschmidt
PR: Lundalogik/lime-elements#3464
File: src/components/text-editor/prosemirror-adapter/plugins/image/inserter.ts:1-11
Timestamp: 2025-03-04T14:27:29.714Z
Learning: In example components (typically found in `src/components/*/examples/`), imports of lime-elements exports should use `@limetech/lime-elements` instead of relative paths. This is because example components aren't included in type declarations and are used in documentation to show developers how to properly use lime-elements components.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3530
File: src/components/text-editor/examples/text-editor-composite.tsx:4-7
Timestamp: 2025-04-16T14:14:18.253Z
Learning: For lime-elements, example files should be self-contained and avoid importing internal implementation details. This includes not importing types from internal files like '../types.ts', especially those marked with @beta. Duplicating simple type definitions in example files is preferred over importing internal types that may change.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3529
File: src/components/lime-ai-avatar/lime-ai-avatar.scss:1-3
Timestamp: 2025-04-25T14:23:56.018Z
Learning: In the lime-elements repository, CSS custom properties prefixed with `--lime-` are considered internal implementation details and should not be documented in JSDoc comments, while other custom properties should be documented as they are part of the public API.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3529
File: src/components/lime-ai-avatar/lime-ai-avatar.scss:24-28
Timestamp: 2025-04-25T14:22:02.157Z
Learning: In lime-elements, CSS custom properties follow a specific naming convention:
1. Internal use variables (not for consumers) are prefixed with `--limel-component-name-`
2. External use variables (intended for consumers) are prefixed with `--component-name-`
Variables documented with JSDoc comments are typically meant for external use.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3518
File: src/components/notched-outline/examples/notched-outline-basic.scss:11-22
Timestamp: 2025-04-14T10:01:18.721Z
Learning: Examples in Lime Elements use Shadow DOM (with `shadow: true` in the component decorator) for style encapsulation, making additional class-based selectors unnecessary. This ensures styles are automatically scoped to each component without leaking to the rest of the application.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3529
File: src/components/lime-ai-avatar/lime-ai-avatar.scss:96-122
Timestamp: 2025-04-25T14:18:07.755Z
Learning: In Lime Elements components that use Shadow DOM (with `shadow: true` in the component decorator), keyframe animation names don't need to be namespaced as they are automatically scoped to the component and won't collide with animations from other components.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3464
File: src/components/text-editor/prosemirror-adapter/plugins/image/view.scss:14-17
Timestamp: 2025-03-11T13:31:46.958Z
Learning: Lime Elements generally does not support unreasonably old browsers, so modern CSS properties like `scale` that have good support in current browsers are preferred over older alternatives.
src/style/internal/shared_input-select-picker.scss (12)
Learnt from: adrianschmidt
PR: Lundalogik/lime-elements#3530
File: src/components/text-editor/examples/text-editor-composite.tsx:4-7
Timestamp: 2025-04-17T09:39:36.254Z
Learning: For lime-elements, example files should import types from the public API using '@limetech/lime-elements' rather than defining duplicate types locally. This includes types like `EditorUiType` which are part of the component's public API.
Learnt from: adrianschmidt
PR: Lundalogik/lime-elements#3464
File: src/components/text-editor/prosemirror-adapter/plugins/image/inserter.ts:1-11
Timestamp: 2025-03-04T13:48:44.712Z
Learning: The lime-elements codebase must use relative imports (even with multiple "../") rather than alias imports or re-exports because they export types to `<repo-root>/dist/types`. Using non-relative imports breaks type generation as import paths from generated type files point to full .ts files rather than .d.ts files.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3530
File: src/components/text-editor/examples/text-editor-composite.tsx:4-7
Timestamp: 2025-04-16T14:14:18.253Z
Learning: For lime-elements, example files should be self-contained and avoid importing internal implementation details. Example files should only import public exports from '@limetech/lime-elements' or use relative imports for other files within the examples folder. Duplicating simple type definitions in example files is preferred over importing internal types.
Learnt from: adrianschmidt
PR: Lundalogik/lime-elements#3464
File: src/components/text-editor/prosemirror-adapter/plugins/image/inserter.ts:1-11
Timestamp: 2025-03-04T14:27:29.714Z
Learning: In example components (typically found in `src/components/*/examples/`), imports of lime-elements exports should use `@limetech/lime-elements` instead of relative paths. This is because example components aren't included in type declarations and are used in documentation to show developers how to properly use lime-elements components.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3530
File: src/components/text-editor/examples/text-editor-composite.tsx:4-7
Timestamp: 2025-04-16T14:14:18.253Z
Learning: For lime-elements, example files should be self-contained and avoid importing internal implementation details. This includes not importing types from internal files like '../types.ts', especially those marked with @beta. Duplicating simple type definitions in example files is preferred over importing internal types that may change.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3529
File: src/components/lime-ai-avatar/lime-ai-avatar.scss:1-3
Timestamp: 2025-04-25T14:23:56.018Z
Learning: In the lime-elements repository, CSS custom properties prefixed with `--lime-` are considered internal implementation details and should not be documented in JSDoc comments, while other custom properties should be documented as they are part of the public API.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3518
File: src/components/notched-outline/examples/notched-outline-basic.scss:11-22
Timestamp: 2025-04-14T10:01:18.721Z
Learning: Examples in Lime Elements use Shadow DOM (with `shadow: true` in the component decorator) for style encapsulation, making additional class-based selectors unnecessary. This ensures styles are automatically scoped to each component without leaking to the rest of the application.
Learnt from: adrianschmidt
PR: Lundalogik/lime-elements#3529
File: src/components/ai-avatar/ai-avatar.scss:20-22
Timestamp: 2025-04-29T14:15:32.104Z
Learning: In components using Shadow DOM (like those in lime-elements), the universal selector `*` is already scoped to the component's shadow tree and won't cause unwanted side effects outside the component. There's no functional difference between `*` and `:host *` in this context.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3529
File: src/components/lime-ai-avatar/lime-ai-avatar.scss:24-28
Timestamp: 2025-04-25T14:22:02.157Z
Learning: In lime-elements, CSS custom properties follow a specific naming convention:
1. Internal use variables (not for consumers) are prefixed with `--limel-component-name-`
2. External use variables (intended for consumers) are prefixed with `--component-name-`
Variables documented with JSDoc comments are typically meant for external use.
Learnt from: CR
PR: Lundalogik/lime-elements#0
File: .cursor/rules/css-class-names-in-components-using-shadow-dom.mdc:0-0
Timestamp: 2025-07-01T14:43:04.238Z
Learning: Applies to src/components/**/*.scss : Do not use BEM-style class names in component CSS files, as components use shadow-DOM.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3529
File: src/components/lime-ai-avatar/lime-ai-avatar.scss:96-122
Timestamp: 2025-04-25T14:18:07.755Z
Learning: In Lime Elements components that use Shadow DOM (with `shadow: true` in the component decorator), keyframe animation names don't need to be namespaced as they are automatically scoped to the component and won't collide with animations from other components.
Learnt from: adrianschmidt
PR: Lundalogik/lime-elements#3529
File: src/components/lime-ai-avatar/lime-ai-avatar.tsx:30-38
Timestamp: 2025-04-25T13:32:56.396Z
Learning: For StencilJS components in lime-elements, prefer using the `<Host>` element to wrap child elements in the render method instead of returning an array of elements. This follows the standard pattern in the codebase and eliminates the need for key attributes.
src/components/button/button.scss (13)
Learnt from: adrianschmidt
PR: Lundalogik/lime-elements#3530
File: src/components/text-editor/examples/text-editor-composite.tsx:4-7
Timestamp: 2025-04-17T09:39:36.254Z
Learning: For lime-elements, example files should import types from the public API using '@limetech/lime-elements' rather than defining duplicate types locally. This includes types like `EditorUiType` which are part of the component's public API.
Learnt from: adrianschmidt
PR: Lundalogik/lime-elements#3464
File: src/components/text-editor/prosemirror-adapter/plugins/image/inserter.ts:1-11
Timestamp: 2025-03-04T14:27:29.714Z
Learning: In example components (typically found in `src/components/*/examples/`), imports of lime-elements exports should use `@limetech/lime-elements` instead of relative paths. This is because example components aren't included in type declarations and are used in documentation to show developers how to properly use lime-elements components.
Learnt from: adrianschmidt
PR: Lundalogik/lime-elements#3464
File: src/components/text-editor/prosemirror-adapter/plugins/image/inserter.ts:1-11
Timestamp: 2025-03-04T13:48:44.712Z
Learning: The lime-elements codebase must use relative imports (even with multiple "../") rather than alias imports or re-exports because they export types to `<repo-root>/dist/types`. Using non-relative imports breaks type generation as import paths from generated type files point to full .ts files rather than .d.ts files.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3530
File: src/components/text-editor/examples/text-editor-composite.tsx:4-7
Timestamp: 2025-04-16T14:14:18.253Z
Learning: For lime-elements, example files should be self-contained and avoid importing internal implementation details. Example files should only import public exports from '@limetech/lime-elements' or use relative imports for other files within the examples folder. Duplicating simple type definitions in example files is preferred over importing internal types.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3530
File: src/components/text-editor/examples/text-editor-composite.tsx:4-7
Timestamp: 2025-04-16T14:14:18.253Z
Learning: For lime-elements, example files should be self-contained and avoid importing internal implementation details. This includes not importing types from internal files like '../types.ts', especially those marked with @beta. Duplicating simple type definitions in example files is preferred over importing internal types that may change.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3518
File: src/components/notched-outline/examples/notched-outline-basic.scss:11-22
Timestamp: 2025-04-14T10:01:18.721Z
Learning: Examples in Lime Elements use Shadow DOM (with `shadow: true` in the component decorator) for style encapsulation, making additional class-based selectors unnecessary. This ensures styles are automatically scoped to each component without leaking to the rest of the application.
Learnt from: CR
PR: Lundalogik/lime-elements#0
File: .cursor/rules/css-class-names-in-components-using-shadow-dom.mdc:0-0
Timestamp: 2025-07-01T14:43:04.238Z
Learning: Applies to src/components/**/*.scss : Do not use BEM-style class names in component CSS files, as components use shadow-DOM.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3529
File: src/components/lime-ai-avatar/lime-ai-avatar.scss:1-3
Timestamp: 2025-04-25T14:23:56.018Z
Learning: In the lime-elements repository, CSS custom properties prefixed with `--lime-` are considered internal implementation details and should not be documented in JSDoc comments, while other custom properties should be documented as they are part of the public API.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3529
File: src/components/lime-ai-avatar/lime-ai-avatar.scss:24-28
Timestamp: 2025-04-25T14:22:02.157Z
Learning: In lime-elements, CSS custom properties follow a specific naming convention:
1. Internal use variables (not for consumers) are prefixed with `--limel-component-name-`
2. External use variables (intended for consumers) are prefixed with `--component-name-`
Variables documented with JSDoc comments are typically meant for external use.
Learnt from: adrianschmidt
PR: Lundalogik/lime-elements#3529
File: src/components/ai-avatar/ai-avatar.scss:20-22
Timestamp: 2025-04-29T14:15:32.104Z
Learning: In components using Shadow DOM (like those in lime-elements), the universal selector `*` is already scoped to the component's shadow tree and won't cause unwanted side effects outside the component. There's no functional difference between `*` and `:host *` in this context.
Learnt from: adrianschmidt
PR: Lundalogik/lime-elements#3529
File: src/components/lime-ai-avatar/lime-ai-avatar.tsx:30-38
Timestamp: 2025-04-25T13:32:56.396Z
Learning: For StencilJS components in lime-elements, prefer using the `<Host>` element to wrap child elements in the render method instead of returning an array of elements. This follows the standard pattern in the codebase and eliminates the need for key attributes.
Learnt from: adrianschmidt
PR: Lundalogik/lime-elements#3529
File: src/components/lime-ai-avatar/lime-ai-avatar.tsx:30-38
Timestamp: 2025-04-25T13:32:56.396Z
Learning: For StencilJS components in lime-elements, prefer using the `<Host>` element to wrap child elements in the render method instead of returning an array of elements, which eliminates the need for key attributes and follows StencilJS best practices.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3529
File: src/components/lime-ai-avatar/lime-ai-avatar.scss:96-122
Timestamp: 2025-04-25T14:18:07.755Z
Learning: In Lime Elements components that use Shadow DOM (with `shadow: true` in the component decorator), keyframe animation names don't need to be namespaced as they are automatically scoped to the component and won't collide with animations from other components.
src/components/form/form.scss (11)
Learnt from: adrianschmidt
PR: Lundalogik/lime-elements#3530
File: src/components/text-editor/examples/text-editor-composite.tsx:4-7
Timestamp: 2025-04-17T09:39:36.254Z
Learning: For lime-elements, example files should import types from the public API using '@limetech/lime-elements' rather than defining duplicate types locally. This includes types like `EditorUiType` which are part of the component's public API.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3530
File: src/components/text-editor/examples/text-editor-composite.tsx:4-7
Timestamp: 2025-04-16T14:14:18.253Z
Learning: For lime-elements, example files should be self-contained and avoid importing internal implementation details. Example files should only import public exports from '@limetech/lime-elements' or use relative imports for other files within the examples folder. Duplicating simple type definitions in example files is preferred over importing internal types.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3529
File: src/components/lime-ai-avatar/lime-ai-avatar.scss:24-28
Timestamp: 2025-04-25T14:22:02.157Z
Learning: In lime-elements, CSS custom properties follow a specific naming convention:
1. Internal use variables (not for consumers) are prefixed with `--limel-component-name-`
2. External use variables (intended for consumers) are prefixed with `--component-name-`
Variables documented with JSDoc comments are typically meant for external use.
Learnt from: adrianschmidt
PR: Lundalogik/lime-elements#3464
File: src/components/text-editor/prosemirror-adapter/plugins/image/inserter.ts:1-11
Timestamp: 2025-03-04T13:48:44.712Z
Learning: The lime-elements codebase must use relative imports (even with multiple "../") rather than alias imports or re-exports because they export types to `<repo-root>/dist/types`. Using non-relative imports breaks type generation as import paths from generated type files point to full .ts files rather than .d.ts files.
Learnt from: adrianschmidt
PR: Lundalogik/lime-elements#3464
File: src/components/text-editor/prosemirror-adapter/plugins/image/inserter.ts:1-11
Timestamp: 2025-03-04T14:27:29.714Z
Learning: In example components (typically found in `src/components/*/examples/`), imports of lime-elements exports should use `@limetech/lime-elements` instead of relative paths. This is because example components aren't included in type declarations and are used in documentation to show developers how to properly use lime-elements components.
Learnt from: CR
PR: Lundalogik/lime-elements#0
File: .cursor/rules/css-class-names-in-components-using-shadow-dom.mdc:0-0
Timestamp: 2025-07-01T14:43:04.238Z
Learning: Applies to src/components/**/*.scss : Do not use BEM-style class names in component CSS files, as components use shadow-DOM.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3530
File: src/components/text-editor/examples/text-editor-composite.tsx:4-7
Timestamp: 2025-04-16T14:14:18.253Z
Learning: For lime-elements, example files should be self-contained and avoid importing internal implementation details. This includes not importing types from internal files like '../types.ts', especially those marked with @beta. Duplicating simple type definitions in example files is preferred over importing internal types that may change.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3518
File: src/components/notched-outline/examples/notched-outline-basic.scss:11-22
Timestamp: 2025-04-14T10:01:18.721Z
Learning: Examples in Lime Elements use Shadow DOM (with `shadow: true` in the component decorator) for style encapsulation, making additional class-based selectors unnecessary. This ensures styles are automatically scoped to each component without leaking to the rest of the application.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3529
File: src/components/lime-ai-avatar/lime-ai-avatar.scss:1-3
Timestamp: 2025-04-25T14:23:56.018Z
Learning: In the lime-elements repository, CSS custom properties prefixed with `--lime-` are considered internal implementation details and should not be documented in JSDoc comments, while other custom properties should be documented as they are part of the public API.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3529
File: src/components/lime-ai-avatar/lime-ai-avatar.scss:96-122
Timestamp: 2025-04-25T14:18:07.755Z
Learning: In Lime Elements components that use Shadow DOM (with `shadow: true` in the component decorator), keyframe animation names don't need to be namespaced as they are automatically scoped to the component and won't collide with animations from other components.
Learnt from: adrianschmidt
PR: Lundalogik/lime-elements#3529
File: src/components/ai-avatar/ai-avatar.scss:20-22
Timestamp: 2025-04-29T14:15:32.104Z
Learning: In components using Shadow DOM (like those in lime-elements), the universal selector `*` is already scoped to the component's shadow tree and won't cause unwanted side effects outside the component. There's no functional difference between `*` and `:host *` in this context.
src/style/internal/variables.scss (13)
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3529
File: src/components/lime-ai-avatar/lime-ai-avatar.scss:24-28
Timestamp: 2025-04-25T14:22:02.157Z
Learning: In lime-elements, CSS custom properties follow a specific naming convention:
1. Internal use variables (not for consumers) are prefixed with `--limel-component-name-`
2. External use variables (intended for consumers) are prefixed with `--component-name-`
Variables documented with JSDoc comments are typically meant for external use.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3529
File: src/components/lime-ai-avatar/lime-ai-avatar.scss:1-3
Timestamp: 2025-04-25T14:23:56.018Z
Learning: In the lime-elements repository, CSS custom properties prefixed with `--lime-` are considered internal implementation details and should not be documented in JSDoc comments, while other custom properties should be documented as they are part of the public API.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3539
File: src/components/text-editor/text-editor.scss:14-14
Timestamp: 2025-04-24T10:16:05.891Z
Learning: In SCSS, prefer using `calc()` function over native SCSS arithmetic operations (like `$variable / 2`) as it aligns with modern SASS recommendations for better CSS compatibility and interoperability with CSS variables.
Learnt from: adrianschmidt
PR: Lundalogik/lime-elements#3530
File: src/components/text-editor/examples/text-editor-composite.tsx:4-7
Timestamp: 2025-04-17T09:39:36.254Z
Learning: For lime-elements, example files should import types from the public API using '@limetech/lime-elements' rather than defining duplicate types locally. This includes types like `EditorUiType` which are part of the component's public API.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3530
File: src/components/text-editor/examples/text-editor-composite.tsx:4-7
Timestamp: 2025-04-16T14:14:18.253Z
Learning: For lime-elements, example files should be self-contained and avoid importing internal implementation details. Example files should only import public exports from '@limetech/lime-elements' or use relative imports for other files within the examples folder. Duplicating simple type definitions in example files is preferred over importing internal types.
Learnt from: adrianschmidt
PR: Lundalogik/lime-elements#3464
File: src/components/text-editor/prosemirror-adapter/plugins/image/inserter.ts:1-11
Timestamp: 2025-03-04T13:48:44.712Z
Learning: The lime-elements codebase must use relative imports (even with multiple "../") rather than alias imports or re-exports because they export types to `<repo-root>/dist/types`. Using non-relative imports breaks type generation as import paths from generated type files point to full .ts files rather than .d.ts files.
Learnt from: CR
PR: Lundalogik/lime-elements#0
File: .cursor/rules/css-class-names-in-components-using-shadow-dom.mdc:0-0
Timestamp: 2025-07-01T14:43:04.238Z
Learning: Applies to src/components/**/*.scss : Do not use BEM-style class names in component CSS files, as components use shadow-DOM.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3567
File: src/components/ai-avatar/ai-avatar.scss:0-0
Timestamp: 2025-05-28T08:37:45.610Z
Learning: In SCSS files, CSS property values can be split across multiple lines when properly indented, particularly for complex values like animation shorthands with CSS custom properties. This is valid SCSS syntax that compiles correctly to CSS and is often the result of auto-formatting tools.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3539
File: src/components/text-editor/text-editor.scss:14-14
Timestamp: 2025-04-24T10:16:05.891Z
Learning: In SCSS, using the `/` operator for division outside of `calc()` is deprecated in Dart Sass and will be removed in Dart Sass 2.0.0. For division operations, use either `math.div($a, $b)` for compile-time calculations or `calc($a / $b)` for calculations that should be preserved in the output CSS and executed at runtime.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3530
File: src/components/text-editor/examples/text-editor-composite.tsx:4-7
Timestamp: 2025-04-16T14:14:18.253Z
Learning: For lime-elements, example files should be self-contained and avoid importing internal implementation details. This includes not importing types from internal files like '../types.ts', especially those marked with @beta. Duplicating simple type definitions in example files is preferred over importing internal types that may change.
Learnt from: adrianschmidt
PR: Lundalogik/lime-elements#3464
File: src/components/text-editor/prosemirror-adapter/plugins/image/inserter.ts:1-11
Timestamp: 2025-03-04T14:27:29.714Z
Learning: In example components (typically found in `src/components/*/examples/`), imports of lime-elements exports should use `@limetech/lime-elements` instead of relative paths. This is because example components aren't included in type declarations and are used in documentation to show developers how to properly use lime-elements components.
Learnt from: adrianschmidt
PR: Lundalogik/lime-elements#3529
File: src/components/ai-avatar/ai-avatar.scss:20-22
Timestamp: 2025-04-29T14:15:32.104Z
Learning: In components using Shadow DOM (like those in lime-elements), the universal selector `*` is already scoped to the component's shadow tree and won't cause unwanted side effects outside the component. There's no functional difference between `*` and `:host *` in this context.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3518
File: src/components/notched-outline/examples/notched-outline-basic.scss:11-22
Timestamp: 2025-04-14T10:01:18.721Z
Learning: Examples in Lime Elements use Shadow DOM (with `shadow: true` in the component decorator) for style encapsulation, making additional class-based selectors unnecessary. This ensures styles are automatically scoped to each component without leaking to the rest of the application.
src/components/input-field/input-field.scss (11)
Learnt from: adrianschmidt
PR: Lundalogik/lime-elements#3530
File: src/components/text-editor/examples/text-editor-composite.tsx:4-7
Timestamp: 2025-04-17T09:39:36.254Z
Learning: For lime-elements, example files should import types from the public API using '@limetech/lime-elements' rather than defining duplicate types locally. This includes types like `EditorUiType` which are part of the component's public API.
Learnt from: adrianschmidt
PR: Lundalogik/lime-elements#3464
File: src/components/text-editor/prosemirror-adapter/plugins/image/inserter.ts:1-11
Timestamp: 2025-03-04T13:48:44.712Z
Learning: The lime-elements codebase must use relative imports (even with multiple "../") rather than alias imports or re-exports because they export types to `<repo-root>/dist/types`. Using non-relative imports breaks type generation as import paths from generated type files point to full .ts files rather than .d.ts files.
Learnt from: adrianschmidt
PR: Lundalogik/lime-elements#3464
File: src/components/text-editor/prosemirror-adapter/plugins/image/inserter.ts:1-11
Timestamp: 2025-03-04T14:27:29.714Z
Learning: In example components (typically found in `src/components/*/examples/`), imports of lime-elements exports should use `@limetech/lime-elements` instead of relative paths. This is because example components aren't included in type declarations and are used in documentation to show developers how to properly use lime-elements components.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3530
File: src/components/text-editor/examples/text-editor-composite.tsx:4-7
Timestamp: 2025-04-16T14:14:18.253Z
Learning: For lime-elements, example files should be self-contained and avoid importing internal implementation details. Example files should only import public exports from '@limetech/lime-elements' or use relative imports for other files within the examples folder. Duplicating simple type definitions in example files is preferred over importing internal types.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3530
File: src/components/text-editor/examples/text-editor-composite.tsx:4-7
Timestamp: 2025-04-16T14:14:18.253Z
Learning: For lime-elements, example files should be self-contained and avoid importing internal implementation details. This includes not importing types from internal files like '../types.ts', especially those marked with @beta. Duplicating simple type definitions in example files is preferred over importing internal types that may change.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3529
File: src/components/lime-ai-avatar/lime-ai-avatar.scss:1-3
Timestamp: 2025-04-25T14:23:56.018Z
Learning: In the lime-elements repository, CSS custom properties prefixed with `--lime-` are considered internal implementation details and should not be documented in JSDoc comments, while other custom properties should be documented as they are part of the public API.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3518
File: src/components/notched-outline/examples/notched-outline-basic.scss:11-22
Timestamp: 2025-04-14T10:01:18.721Z
Learning: Examples in Lime Elements use Shadow DOM (with `shadow: true` in the component decorator) for style encapsulation, making additional class-based selectors unnecessary. This ensures styles are automatically scoped to each component without leaking to the rest of the application.
Learnt from: CR
PR: Lundalogik/lime-elements#0
File: .cursor/rules/css-class-names-in-components-using-shadow-dom.mdc:0-0
Timestamp: 2025-07-01T14:43:04.238Z
Learning: Applies to src/components/**/*.scss : Do not use BEM-style class names in component CSS files, as components use shadow-DOM.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3529
File: src/components/lime-ai-avatar/lime-ai-avatar.scss:24-28
Timestamp: 2025-04-25T14:22:02.157Z
Learning: In lime-elements, CSS custom properties follow a specific naming convention:
1. Internal use variables (not for consumers) are prefixed with `--limel-component-name-`
2. External use variables (intended for consumers) are prefixed with `--component-name-`
Variables documented with JSDoc comments are typically meant for external use.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3529
File: src/components/lime-ai-avatar/lime-ai-avatar.scss:96-122
Timestamp: 2025-04-25T14:18:07.755Z
Learning: In Lime Elements components that use Shadow DOM (with `shadow: true` in the component decorator), keyframe animation names don't need to be namespaced as they are automatically scoped to the component and won't collide with animations from other components.
Learnt from: adrianschmidt
PR: Lundalogik/lime-elements#3529
File: src/components/ai-avatar/ai-avatar.scss:20-22
Timestamp: 2025-04-29T14:15:32.104Z
Learning: In components using Shadow DOM (like those in lime-elements), the universal selector `*` is already scoped to the component's shadow tree and won't cause unwanted side effects outside the component. There's no functional difference between `*` and `:host *` in this context.
src/components/progress-flow/progress-flow.scss (4)
Learnt from: CR
PR: Lundalogik/lime-elements#0
File: .cursor/rules/css-class-names-in-components-using-shadow-dom.mdc:0-0
Timestamp: 2025-07-01T14:43:04.238Z
Learning: Applies to src/components/**/*.scss : Do not use BEM-style class names in component CSS files, as components use shadow-DOM.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3539
File: src/components/text-editor/text-editor.scss:14-14
Timestamp: 2025-04-24T10:16:05.891Z
Learning: In SCSS, prefer using `calc()` function over native SCSS arithmetic operations (like `$variable / 2`) as it aligns with modern SASS recommendations for better CSS compatibility and interoperability with CSS variables.
Learnt from: adrianschmidt
PR: Lundalogik/lime-elements#3530
File: src/components/text-editor/examples/text-editor-composite.tsx:4-7
Timestamp: 2025-04-17T09:39:36.254Z
Learning: For lime-elements, example files should import types from the public API using '@limetech/lime-elements' rather than defining duplicate types locally. This includes types like `EditorUiType` which are part of the component's public API.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3529
File: src/components/lime-ai-avatar/lime-ai-avatar.scss:24-28
Timestamp: 2025-04-25T14:22:02.157Z
Learning: In lime-elements, CSS custom properties follow a specific naming convention:
1. Internal use variables (not for consumers) are prefixed with `--limel-component-name-`
2. External use variables (intended for consumers) are prefixed with `--component-name-`
Variables documented with JSDoc comments are typically meant for external use.
src/components/banner/banner.scss (11)
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3529
File: src/components/lime-ai-avatar/lime-ai-avatar.scss:24-28
Timestamp: 2025-04-25T14:22:02.157Z
Learning: In lime-elements, CSS custom properties follow a specific naming convention:
1. Internal use variables (not for consumers) are prefixed with `--limel-component-name-`
2. External use variables (intended for consumers) are prefixed with `--component-name-`
Variables documented with JSDoc comments are typically meant for external use.
Learnt from: adrianschmidt
PR: Lundalogik/lime-elements#3464
File: src/components/text-editor/prosemirror-adapter/plugins/image/inserter.ts:1-11
Timestamp: 2025-03-04T13:48:44.712Z
Learning: The lime-elements codebase must use relative imports (even with multiple "../") rather than alias imports or re-exports because they export types to `<repo-root>/dist/types`. Using non-relative imports breaks type generation as import paths from generated type files point to full .ts files rather than .d.ts files.
Learnt from: adrianschmidt
PR: Lundalogik/lime-elements#3530
File: src/components/text-editor/examples/text-editor-composite.tsx:4-7
Timestamp: 2025-04-17T09:39:36.254Z
Learning: For lime-elements, example files should import types from the public API using '@limetech/lime-elements' rather than defining duplicate types locally. This includes types like `EditorUiType` which are part of the component's public API.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3529
File: src/components/lime-ai-avatar/lime-ai-avatar.scss:1-3
Timestamp: 2025-04-25T14:23:56.018Z
Learning: In the lime-elements repository, CSS custom properties prefixed with `--lime-` are considered internal implementation details and should not be documented in JSDoc comments, while other custom properties should be documented as they are part of the public API.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3530
File: src/components/text-editor/examples/text-editor-composite.tsx:4-7
Timestamp: 2025-04-16T14:14:18.253Z
Learning: For lime-elements, example files should be self-contained and avoid importing internal implementation details. Example files should only import public exports from '@limetech/lime-elements' or use relative imports for other files within the examples folder. Duplicating simple type definitions in example files is preferred over importing internal types.
Learnt from: adrianschmidt
PR: Lundalogik/lime-elements#3464
File: src/components/text-editor/prosemirror-adapter/plugins/image/inserter.ts:1-11
Timestamp: 2025-03-04T14:27:29.714Z
Learning: In example components (typically found in `src/components/*/examples/`), imports of lime-elements exports should use `@limetech/lime-elements` instead of relative paths. This is because example components aren't included in type declarations and are used in documentation to show developers how to properly use lime-elements components.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3530
File: src/components/text-editor/examples/text-editor-composite.tsx:4-7
Timestamp: 2025-04-16T14:14:18.253Z
Learning: For lime-elements, example files should be self-contained and avoid importing internal implementation details. This includes not importing types from internal files like '../types.ts', especially those marked with @beta. Duplicating simple type definitions in example files is preferred over importing internal types that may change.
Learnt from: CR
PR: Lundalogik/lime-elements#0
File: .cursor/rules/css-class-names-in-components-using-shadow-dom.mdc:0-0
Timestamp: 2025-07-01T14:43:04.238Z
Learning: Applies to src/components/**/*.scss : Do not use BEM-style class names in component CSS files, as components use shadow-DOM.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3518
File: src/components/notched-outline/examples/notched-outline-basic.scss:11-22
Timestamp: 2025-04-14T10:01:18.721Z
Learning: Examples in Lime Elements use Shadow DOM (with `shadow: true` in the component decorator) for style encapsulation, making additional class-based selectors unnecessary. This ensures styles are automatically scoped to each component without leaking to the rest of the application.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3529
File: src/components/lime-ai-avatar/lime-ai-avatar.scss:96-122
Timestamp: 2025-04-25T14:18:07.755Z
Learning: In Lime Elements components that use Shadow DOM (with `shadow: true` in the component decorator), keyframe animation names don't need to be namespaced as they are automatically scoped to the component and won't collide with animations from other components.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3464
File: src/components/text-editor/prosemirror-adapter/plugins/image/view.scss:14-17
Timestamp: 2025-03-11T13:31:46.958Z
Learning: Lime Elements generally does not support unreasonably old browsers, so modern CSS properties like `scale` that have good support in current browsers are preferred over older alternatives.
src/components/checkbox/checkbox.scss (11)
Learnt from: adrianschmidt
PR: Lundalogik/lime-elements#3530
File: src/components/text-editor/examples/text-editor-composite.tsx:4-7
Timestamp: 2025-04-17T09:39:36.254Z
Learning: For lime-elements, example files should import types from the public API using '@limetech/lime-elements' rather than defining duplicate types locally. This includes types like `EditorUiType` which are part of the component's public API.
Learnt from: adrianschmidt
PR: Lundalogik/lime-elements#3464
File: src/components/text-editor/prosemirror-adapter/plugins/image/inserter.ts:1-11
Timestamp: 2025-03-04T14:27:29.714Z
Learning: In example components (typically found in `src/components/*/examples/`), imports of lime-elements exports should use `@limetech/lime-elements` instead of relative paths. This is because example components aren't included in type declarations and are used in documentation to show developers how to properly use lime-elements components.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3530
File: src/components/text-editor/examples/text-editor-composite.tsx:4-7
Timestamp: 2025-04-16T14:14:18.253Z
Learning: For lime-elements, example files should be self-contained and avoid importing internal implementation details. Example files should only import public exports from '@limetech/lime-elements' or use relative imports for other files within the examples folder. Duplicating simple type definitions in example files is preferred over importing internal types.
Learnt from: adrianschmidt
PR: Lundalogik/lime-elements#3464
File: src/components/text-editor/prosemirror-adapter/plugins/image/inserter.ts:1-11
Timestamp: 2025-03-04T13:48:44.712Z
Learning: The lime-elements codebase must use relative imports (even with multiple "../") rather than alias imports or re-exports because they export types to `<repo-root>/dist/types`. Using non-relative imports breaks type generation as import paths from generated type files point to full .ts files rather than .d.ts files.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3529
File: src/components/lime-ai-avatar/lime-ai-avatar.scss:1-3
Timestamp: 2025-04-25T14:23:56.018Z
Learning: In the lime-elements repository, CSS custom properties prefixed with `--lime-` are considered internal implementation details and should not be documented in JSDoc comments, while other custom properties should be documented as they are part of the public API.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3530
File: src/components/text-editor/examples/text-editor-composite.tsx:4-7
Timestamp: 2025-04-16T14:14:18.253Z
Learning: For lime-elements, example files should be self-contained and avoid importing internal implementation details. This includes not importing types from internal files like '../types.ts', especially those marked with @beta. Duplicating simple type definitions in example files is preferred over importing internal types that may change.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3529
File: src/components/lime-ai-avatar/lime-ai-avatar.scss:24-28
Timestamp: 2025-04-25T14:22:02.157Z
Learning: In lime-elements, CSS custom properties follow a specific naming convention:
1. Internal use variables (not for consumers) are prefixed with `--limel-component-name-`
2. External use variables (intended for consumers) are prefixed with `--component-name-`
Variables documented with JSDoc comments are typically meant for external use.
Learnt from: CR
PR: Lundalogik/lime-elements#0
File: .cursor/rules/css-class-names-in-components-using-shadow-dom.mdc:0-0
Timestamp: 2025-07-01T14:43:04.238Z
Learning: Applies to src/components/**/*.scss : Do not use BEM-style class names in component CSS files, as components use shadow-DOM.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3518
File: src/components/notched-outline/examples/notched-outline-basic.scss:11-22
Timestamp: 2025-04-14T10:01:18.721Z
Learning: Examples in Lime Elements use Shadow DOM (with `shadow: true` in the component decorator) for style encapsulation, making additional class-based selectors unnecessary. This ensures styles are automatically scoped to each component without leaking to the rest of the application.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3518
File: src/components/chip-set/chip-set.tsx:367-385
Timestamp: 2025-04-14T12:22:22.298Z
Learning: In limel-chip-set, the onClick handler should be placed on the content div (<div slot="content">) rather than on the limel-notched-outline component, and should only be applied when type is 'input'.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3529
File: src/components/lime-ai-avatar/lime-ai-avatar.scss:96-122
Timestamp: 2025-04-25T14:18:07.755Z
Learning: In Lime Elements components that use Shadow DOM (with `shadow: true` in the component decorator), keyframe animation names don't need to be namespaced as they are automatically scoped to the component and won't collide with animations from other components.
src/style/internal/lime-typography.scss (9)
Learnt from: adrianschmidt
PR: Lundalogik/lime-elements#3530
File: src/components/text-editor/examples/text-editor-composite.tsx:4-7
Timestamp: 2025-04-17T09:39:36.254Z
Learning: For lime-elements, example files should import types from the public API using '@limetech/lime-elements' rather than defining duplicate types locally. This includes types like `EditorUiType` which are part of the component's public API.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3529
File: src/components/lime-ai-avatar/lime-ai-avatar.scss:1-3
Timestamp: 2025-04-25T14:23:56.018Z
Learning: In the lime-elements repository, CSS custom properties prefixed with `--lime-` are considered internal implementation details and should not be documented in JSDoc comments, while other custom properties should be documented as they are part of the public API.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3530
File: src/components/text-editor/examples/text-editor-composite.tsx:4-7
Timestamp: 2025-04-16T14:14:18.253Z
Learning: For lime-elements, example files should be self-contained and avoid importing internal implementation details. This includes not importing types from internal files like '../types.ts', especially those marked with @beta. Duplicating simple type definitions in example files is preferred over importing internal types that may change.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3529
File: src/components/lime-ai-avatar/lime-ai-avatar.scss:24-28
Timestamp: 2025-04-25T14:22:02.157Z
Learning: In lime-elements, CSS custom properties follow a specific naming convention:
1. Internal use variables (not for consumers) are prefixed with `--limel-component-name-`
2. External use variables (intended for consumers) are prefixed with `--component-name-`
Variables documented with JSDoc comments are typically meant for external use.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3530
File: src/components/text-editor/examples/text-editor-composite.tsx:4-7
Timestamp: 2025-04-16T14:14:18.253Z
Learning: For lime-elements, example files should be self-contained and avoid importing internal implementation details. Example files should only import public exports from '@limetech/lime-elements' or use relative imports for other files within the examples folder. Duplicating simple type definitions in example files is preferred over importing internal types.
Learnt from: CR
PR: Lundalogik/lime-elements#0
File: .cursor/rules/css-class-names-in-components-using-shadow-dom.mdc:0-0
Timestamp: 2025-07-01T14:43:04.238Z
Learning: Applies to src/components/**/*.scss : Do not use BEM-style class names in component CSS files, as components use shadow-DOM.
Learnt from: adrianschmidt
PR: Lundalogik/lime-elements#3464
File: src/components/text-editor/prosemirror-adapter/plugins/image/inserter.ts:1-11
Timestamp: 2025-03-04T13:48:44.712Z
Learning: The lime-elements codebase must use relative imports (even with multiple "../") rather than alias imports or re-exports because they export types to `<repo-root>/dist/types`. Using non-relative imports breaks type generation as import paths from generated type files point to full .ts files rather than .d.ts files.
Learnt from: adrianschmidt
PR: Lundalogik/lime-elements#3464
File: src/components/text-editor/prosemirror-adapter/plugins/image/inserter.ts:1-11
Timestamp: 2025-03-04T14:27:29.714Z
Learning: In example components (typically found in `src/components/*/examples/`), imports of lime-elements exports should use `@limetech/lime-elements` instead of relative paths. This is because example components aren't included in type declarations and are used in documentation to show developers how to properly use lime-elements components.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3539
File: src/components/text-editor/text-editor.scss:14-14
Timestamp: 2025-04-24T10:16:05.891Z
Learning: In SCSS, prefer using `calc()` function over native SCSS arithmetic operations (like `$variable / 2`) as it aligns with modern SASS recommendations for better CSS compatibility and interoperability with CSS variables.
src/components/file-viewer/file-viewer.scss (5)
Learnt from: adrianschmidt
PR: Lundalogik/lime-elements#3530
File: src/components/text-editor/examples/text-editor-composite.tsx:4-7
Timestamp: 2025-04-17T09:39:36.254Z
Learning: For lime-elements, example files should import types from the public API using '@limetech/lime-elements' rather than defining duplicate types locally. This includes types like `EditorUiType` which are part of the component's public API.
Learnt from: CR
PR: Lundalogik/lime-elements#0
File: .cursor/rules/css-class-names-in-components-using-shadow-dom.mdc:0-0
Timestamp: 2025-07-01T14:43:04.238Z
Learning: Applies to src/components/**/*.scss : Do not use BEM-style class names in component CSS files, as components use shadow-DOM.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3530
File: src/components/text-editor/examples/text-editor-composite.tsx:4-7
Timestamp: 2025-04-16T14:14:18.253Z
Learning: For lime-elements, example files should be self-contained and avoid importing internal implementation details. This includes not importing types from internal files like '../types.ts', especially those marked with @beta. Duplicating simple type definitions in example files is preferred over importing internal types that may change.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3529
File: src/components/lime-ai-avatar/lime-ai-avatar.scss:24-28
Timestamp: 2025-04-25T14:22:02.157Z
Learning: In lime-elements, CSS custom properties follow a specific naming convention:
1. Internal use variables (not for consumers) are prefixed with `--limel-component-name-`
2. External use variables (intended for consumers) are prefixed with `--component-name-`
Variables documented with JSDoc comments are typically meant for external use.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3518
File: src/components/notched-outline/examples/notched-outline-basic.scss:11-22
Timestamp: 2025-04-14T10:01:18.721Z
Learning: Examples in Lime Elements use Shadow DOM (with `shadow: true` in the component decorator) for style encapsulation, making additional class-based selectors unnecessary. This ensures styles are automatically scoped to each component without leaking to the rest of the application.
src/components/dock/dock.scss (6)
Learnt from: CR
PR: Lundalogik/lime-elements#0
File: .cursor/rules/css-class-names-in-components-using-shadow-dom.mdc:0-0
Timestamp: 2025-07-01T14:43:04.238Z
Learning: Applies to src/components/**/*.scss : Do not use BEM-style class names in component CSS files, as components use shadow-DOM.
Learnt from: adrianschmidt
PR: Lundalogik/lime-elements#3530
File: src/components/text-editor/examples/text-editor-composite.tsx:4-7
Timestamp: 2025-04-17T09:39:36.254Z
Learning: For lime-elements, example files should import types from the public API using '@limetech/lime-elements' rather than defining duplicate types locally. This includes types like `EditorUiType` which are part of the component's public API.
Learnt from: adrianschmidt
PR: Lundalogik/lime-elements#3464
File: src/components/text-editor/prosemirror-adapter/plugins/image/inserter.ts:1-11
Timestamp: 2025-03-04T13:48:44.712Z
Learning: The lime-elements codebase must use relative imports (even with multiple "../") rather than alias imports or re-exports because they export types to `<repo-root>/dist/types`. Using non-relative imports breaks type generation as import paths from generated type files point to full .ts files rather than .d.ts files.
Learnt from: adrianschmidt
PR: Lundalogik/lime-elements#3464
File: src/components/text-editor/prosemirror-adapter/plugins/image/inserter.ts:1-11
Timestamp: 2025-03-04T14:27:29.714Z
Learning: In example components (typically found in `src/components/*/examples/`), imports of lime-elements exports should use `@limetech/lime-elements` instead of relative paths. This is because example components aren't included in type declarations and are used in documentation to show developers how to properly use lime-elements components.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3529
File: src/components/lime-ai-avatar/lime-ai-avatar.scss:1-3
Timestamp: 2025-04-25T14:23:56.018Z
Learning: In the lime-elements repository, CSS custom properties prefixed with `--lime-` are considered internal implementation details and should not be documented in JSDoc comments, while other custom properties should be documented as they are part of the public API.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3529
File: src/components/lime-ai-avatar/lime-ai-avatar.scss:24-28
Timestamp: 2025-04-25T14:22:02.157Z
Learning: In lime-elements, CSS custom properties follow a specific naming convention:
1. Internal use variables (not for consumers) are prefixed with `--limel-component-name-`
2. External use variables (intended for consumers) are prefixed with `--component-name-`
Variables documented with JSDoc comments are typically meant for external use.
src/style/internal/lime-theme.scss (11)
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3529
File: src/components/lime-ai-avatar/lime-ai-avatar.scss:1-3
Timestamp: 2025-04-25T14:23:56.018Z
Learning: In the lime-elements repository, CSS custom properties prefixed with `--lime-` are considered internal implementation details and should not be documented in JSDoc comments, while other custom properties should be documented as they are part of the public API.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3529
File: src/components/lime-ai-avatar/lime-ai-avatar.scss:24-28
Timestamp: 2025-04-25T14:22:02.157Z
Learning: In lime-elements, CSS custom properties follow a specific naming convention:
1. Internal use variables (not for consumers) are prefixed with `--limel-component-name-`
2. External use variables (intended for consumers) are prefixed with `--component-name-`
Variables documented with JSDoc comments are typically meant for external use.
Learnt from: adrianschmidt
PR: Lundalogik/lime-elements#3530
File: src/components/text-editor/examples/text-editor-composite.tsx:4-7
Timestamp: 2025-04-17T09:39:36.254Z
Learning: For lime-elements, example files should import types from the public API using '@limetech/lime-elements' rather than defining duplicate types locally. This includes types like `EditorUiType` which are part of the component's public API.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3530
File: src/components/text-editor/examples/text-editor-composite.tsx:4-7
Timestamp: 2025-04-16T14:14:18.253Z
Learning: For lime-elements, example files should be self-contained and avoid importing internal implementation details. Example files should only import public exports from '@limetech/lime-elements' or use relative imports for other files within the examples folder. Duplicating simple type definitions in example files is preferred over importing internal types.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3518
File: src/components/notched-outline/examples/notched-outline-basic.scss:11-22
Timestamp: 2025-04-14T10:01:18.721Z
Learning: Examples in Lime Elements use Shadow DOM (with `shadow: true` in the component decorator) for style encapsulation, making additional class-based selectors unnecessary. This ensures styles are automatically scoped to each component without leaking to the rest of the application.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3530
File: src/components/text-editor/examples/text-editor-composite.tsx:4-7
Timestamp: 2025-04-16T14:14:18.253Z
Learning: For lime-elements, example files should be self-contained and avoid importing internal implementation details. This includes not importing types from internal files like '../types.ts', especially those marked with @beta. Duplicating simple type definitions in example files is preferred over importing internal types that may change.
Learnt from: adrianschmidt
PR: Lundalogik/lime-elements#3464
File: src/components/text-editor/prosemirror-adapter/plugins/image/inserter.ts:1-11
Timestamp: 2025-03-04T14:27:29.714Z
Learning: In example components (typically found in `src/components/*/examples/`), imports of lime-elements exports should use `@limetech/lime-elements` instead of relative paths. This is because example components aren't included in type declarations and are used in documentation to show developers how to properly use lime-elements components.
Learnt from: adrianschmidt
PR: Lundalogik/lime-elements#3464
File: src/components/text-editor/prosemirror-adapter/plugins/image/inserter.ts:1-11
Timestamp: 2025-03-04T13:48:44.712Z
Learning: The lime-elements codebase must use relative imports (even with multiple "../") rather than alias imports or re-exports because they export types to `<repo-root>/dist/types`. Using non-relative imports breaks type generation as import paths from generated type files point to full .ts files rather than .d.ts files.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3529
File: src/components/lime-ai-avatar/lime-ai-avatar.scss:96-122
Timestamp: 2025-04-25T14:18:07.755Z
Learning: In Lime Elements components that use Shadow DOM (with `shadow: true` in the component decorator), keyframe animation names don't need to be namespaced as they are automatically scoped to the component and won't collide with animations from other components.
Learnt from: CR
PR: Lundalogik/lime-elements#0
File: .cursor/rules/css-class-names-in-components-using-shadow-dom.mdc:0-0
Timestamp: 2025-07-01T14:43:04.238Z
Learning: Applies to src/components/**/*.scss : Do not use BEM-style class names in component CSS files, as components use shadow-DOM.
Learnt from: adrianschmidt
PR: Lundalogik/lime-elements#3529
File: src/components/ai-avatar/ai-avatar.scss:20-22
Timestamp: 2025-04-29T14:15:32.104Z
Learning: In components using Shadow DOM (like those in lime-elements), the universal selector `*` is already scoped to the component's shadow tree and won't cause unwanted side effects outside the component. There's no functional difference between `*` and `:host *` in this context.
src/global/core-styles.scss (11)
Learnt from: adrianschmidt
PR: Lundalogik/lime-elements#3464
File: src/components/text-editor/prosemirror-adapter/plugins/image/inserter.ts:1-11
Timestamp: 2025-03-04T13:48:44.712Z
Learning: The lime-elements codebase must use relative imports (even with multiple "../") rather than alias imports or re-exports because they export types to `<repo-root>/dist/types`. Using non-relative imports breaks type generation as import paths from generated type files point to full .ts files rather than .d.ts files.
Learnt from: adrianschmidt
PR: Lundalogik/lime-elements#3530
File: src/components/text-editor/examples/text-editor-composite.tsx:4-7
Timestamp: 2025-04-17T09:39:36.254Z
Learning: For lime-elements, example files should import types from the public API using '@limetech/lime-elements' rather than defining duplicate types locally. This includes types like `EditorUiType` which are part of the component's public API.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3530
File: src/components/text-editor/examples/text-editor-composite.tsx:4-7
Timestamp: 2025-04-16T14:14:18.253Z
Learning: For lime-elements, example files should be self-contained and avoid importing internal implementation details. Example files should only import public exports from '@limetech/lime-elements' or use relative imports for other files within the examples folder. Duplicating simple type definitions in example files is preferred over importing internal types.
Learnt from: adrianschmidt
PR: Lundalogik/lime-elements#3464
File: src/components/text-editor/prosemirror-adapter/plugins/image/inserter.ts:1-11
Timestamp: 2025-03-04T14:27:29.714Z
Learning: In example components (typically found in `src/components/*/examples/`), imports of lime-elements exports should use `@limetech/lime-elements` instead of relative paths. This is because example components aren't included in type declarations and are used in documentation to show developers how to properly use lime-elements components.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3530
File: src/components/text-editor/examples/text-editor-composite.tsx:4-7
Timestamp: 2025-04-16T14:14:18.253Z
Learning: For lime-elements, example files should be self-contained and avoid importing internal implementation details. This includes not importing types from internal files like '../types.ts', especially those marked with @beta. Duplicating simple type definitions in example files is preferred over importing internal types that may change.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3529
File: src/components/lime-ai-avatar/lime-ai-avatar.scss:1-3
Timestamp: 2025-04-25T14:23:56.018Z
Learning: In the lime-elements repository, CSS custom properties prefixed with `--lime-` are considered internal implementation details and should not be documented in JSDoc comments, while other custom properties should be documented as they are part of the public API.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3529
File: src/components/lime-ai-avatar/lime-ai-avatar.scss:24-28
Timestamp: 2025-04-25T14:22:02.157Z
Learning: In lime-elements, CSS custom properties follow a specific naming convention:
1. Internal use variables (not for consumers) are prefixed with `--limel-component-name-`
2. External use variables (intended for consumers) are prefixed with `--component-name-`
Variables documented with JSDoc comments are typically meant for external use.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3518
File: src/components/notched-outline/examples/notched-outline-basic.scss:11-22
Timestamp: 2025-04-14T10:01:18.721Z
Learning: Examples in Lime Elements use Shadow DOM (with `shadow: true` in the component decorator) for style encapsulation, making additional class-based selectors unnecessary. This ensures styles are automatically scoped to each component without leaking to the rest of the application.
Learnt from: CR
PR: Lundalogik/lime-elements#0
File: .cursor/rules/css-class-names-in-components-using-shadow-dom.mdc:0-0
Timestamp: 2025-07-01T14:43:04.238Z
Learning: Applies to src/components/**/*.scss : Do not use BEM-style class names in component CSS files, as components use shadow-DOM.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3529
File: src/components/lime-ai-avatar/lime-ai-avatar.scss:96-122
Timestamp: 2025-04-25T14:18:07.755Z
Learning: In Lime Elements components that use Shadow DOM (with `shadow: true` in the component decorator), keyframe animation names don't need to be namespaced as they are automatically scoped to the component and won't collide with animations from other components.
Learnt from: adrianschmidt
PR: Lundalogik/lime-elements#3529
File: src/components/ai-avatar/ai-avatar.scss:20-22
Timestamp: 2025-04-29T14:15:32.104Z
Learning: In components using Shadow DOM (like those in lime-elements), the universal selector `*` is already scoped to the component's shadow tree and won't cause unwanted side effects outside the component. There's no functional difference between `*` and `:host *` in this context.
src/style/brand-colors.scss (5)
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3529
File: src/components/lime-ai-avatar/lime-ai-avatar.scss:1-3
Timestamp: 2025-04-25T14:23:56.018Z
Learning: In the lime-elements repository, CSS custom properties prefixed with `--lime-` are considered internal implementation details and should not be documented in JSDoc comments, while other custom properties should be documented as they are part of the public API.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3529
File: src/components/lime-ai-avatar/lime-ai-avatar.scss:24-28
Timestamp: 2025-04-25T14:22:02.157Z
Learning: In lime-elements, CSS custom properties follow a specific naming convention:
1. Internal use variables (not for consumers) are prefixed with `--limel-component-name-`
2. External use variables (intended for consumers) are prefixed with `--component-name-`
Variables documented with JSDoc comments are typically meant for external use.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3567
File: src/components/ai-avatar/ai-avatar.scss:0-0
Timestamp: 2025-05-28T08:37:45.610Z
Learning: In SCSS files, CSS property values can be split across multiple lines when properly indented, particularly for complex values like animation shorthands with CSS custom properties. This is valid SCSS syntax that compiles correctly to CSS and is often the result of auto-formatting tools.
Learnt from: CR
PR: Lundalogik/lime-elements#0
File: .cursor/rules/css-class-names-in-components-using-shadow-dom.mdc:0-0
Timestamp: 2025-07-01T14:43:04.238Z
Learning: Applies to src/components/**/*.scss : Do not use BEM-style class names in component CSS files, as components use shadow-DOM.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3530
File: src/components/text-editor/examples/text-editor-composite.tsx:4-7
Timestamp: 2025-04-16T14:14:18.253Z
Learning: For lime-elements, example files should be self-contained and avoid importing internal implementation details. Example files should only import public exports from '@limetech/lime-elements' or use relative imports for other files within the examples folder. Duplicating simple type definitions in example files is preferred over importing internal types.
src/components/switch/switch.scss (11)
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3518
File: src/components/notched-outline/examples/notched-outline-basic.scss:11-22
Timestamp: 2025-04-14T10:01:18.721Z
Learning: Examples in Lime Elements use Shadow DOM (with `shadow: true` in the component decorator) for style encapsulation, making additional class-based selectors unnecessary. This ensures styles are automatically scoped to each component without leaking to the rest of the application.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3529
File: src/components/lime-ai-avatar/lime-ai-avatar.scss:1-3
Timestamp: 2025-04-25T14:23:56.018Z
Learning: In the lime-elements repository, CSS custom properties prefixed with `--lime-` are considered internal implementation details and should not be documented in JSDoc comments, while other custom properties should be documented as they are part of the public API.
Learnt from: adrianschmidt
PR: Lundalogik/lime-elements#3530
File: src/components/text-editor/examples/text-editor-composite.tsx:4-7
Timestamp: 2025-04-17T09:39:36.254Z
Learning: For lime-elements, example files should import types from the public API using '@limetech/lime-elements' rather than defining duplicate types locally. This includes types like `EditorUiType` which are part of the component's public API.
Learnt from: CR
PR: Lundalogik/lime-elements#0
File: .cursor/rules/css-class-names-in-components-using-shadow-dom.mdc:0-0
Timestamp: 2025-07-01T14:43:04.238Z
Learning: Applies to src/components/**/*.scss : Do not use BEM-style class names in component CSS files, as components use shadow-DOM.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3529
File: src/components/lime-ai-avatar/lime-ai-avatar.scss:24-28
Timestamp: 2025-04-25T14:22:02.157Z
Learning: In lime-elements, CSS custom properties follow a specific naming convention:
1. Internal use variables (not for consumers) are prefixed with `--limel-component-name-`
2. External use variables (intended for consumers) are prefixed with `--component-name-`
Variables documented with JSDoc comments are typically meant for external use.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3529
File: src/components/lime-ai-avatar/lime-ai-avatar.scss:96-122
Timestamp: 2025-04-25T14:18:07.755Z
Learning: In Lime Elements components that use Shadow DOM (with `shadow: true` in the component decorator), keyframe animation names don't need to be namespaced as they are automatically scoped to the component and won't collide with animations from other components.
Learnt from: adrianschmidt
PR: Lundalogik/lime-elements#3464
File: src/components/text-editor/prosemirror-adapter/plugins/image/inserter.ts:1-11
Timestamp: 2025-03-04T14:27:29.714Z
Learning: In example components (typically found in `src/components/*/examples/`), imports of lime-elements exports should use `@limetech/lime-elements` instead of relative paths. This is because example components aren't included in type declarations and are used in documentation to show developers how to properly use lime-elements components.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3530
File: src/components/text-editor/examples/text-editor-composite.tsx:4-7
Timestamp: 2025-04-16T14:14:18.253Z
Learning: For lime-elements, example files should be self-contained and avoid importing internal implementation details. Example files should only import public exports from '@limetech/lime-elements' or use relative imports for other files within the examples folder. Duplicating simple type definitions in example files is preferred over importing internal types.
Learnt from: adrianschmidt
PR: Lundalogik/lime-elements#3464
File: src/components/text-editor/prosemirror-adapter/plugins/image/inserter.ts:1-11
Timestamp: 2025-03-04T13:48:44.712Z
Learning: The lime-elements codebase must use relative imports (even with multiple "../") rather than alias imports or re-exports because they export types to `<repo-root>/dist/types`. Using non-relative imports breaks type generation as import paths from generated type files point to full .ts files rather than .d.ts files.
Learnt from: adrianschmidt
PR: Lundalogik/lime-elements#3529
File: src/components/ai-avatar/ai-avatar.scss:20-22
Timestamp: 2025-04-29T14:15:32.104Z
Learning: In components using Shadow DOM (like those in lime-elements), the universal selector `*` is already scoped to the component's shadow tree and won't cause unwanted side effects outside the component. There's no functional difference between `*` and `:host *` in this context.
Learnt from: Kiarokh
PR: Lundalogik/lime-elements#3530
File: src/components/text-editor/examples/text-editor-composite.tsx:4-7
Timestamp: 2025-04-16T14:14:18.253Z
Learning: For lime-elements, example files should be self-contained and avoid importing internal implementation details. This includes not importing types from internal files like '../types.ts', especially those marked with @beta. Duplicating simple type definitions in example files is preferred over importing internal types that may change.
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)
- GitHub Check: Docs / Publish Docs
- GitHub Check: Build
- GitHub Check: Test
🔇 Additional comments (19)
src/style/internal/variables.scss (1)
8-10: Double-check thatfunctionsis side-effect-freeThis file is pulled into every component, so any CSS emitted transitively will bloat every bundle. Please confirm that
../functionsonly provides Sass helpers and does not emit CSS on load.src/components/slider/slider.scss (1)
5-6: Import addition looks goodThe new
lime-themeimport follows the established pattern used across other components and should compile without issues.src/components/spinner/spinner.scss (1)
3-3: Consistent theming import – OKIncluding
lime-themekeeps this file aligned with the rest of the codebase. No further action needed.src/components/circular-progress/circular-progress.scss (1)
3-3: Import aligns with new theming strategyNo problems spotted with the additional import.
src/components/dock/dock.scss (1)
3-3: Shared variables import is fine
variables.scssis now the single source of truth for shared constants, so this addition is correct.src/components/list/list.scss (1)
4-4: Theming import approvedThe added
lime-themeimport is correct and needed for the centralised style system.src/components/chip-set/chip-set.scss (1)
5-6: Import looks correct – no further action neededThe new
@use '../../style/internal/lime-theme';brings the MDC-based theme variables into this stylesheet, which are later referenced viavar(--mdc-theme-*). All good.src/components/slider/partial-styles/_readonly.scss (1)
1-1: Theme import is appropriateThis partial relies on
var(--mdc-theme-primary), so importinglime-themehere is warranted.src/components/linear-progress/linear-progress.scss (1)
1-2: Good addition – theme variables now availableThe component now pulls in the shared theme, allowing safe use of
var(--mdc-theme-primary).src/components/dialog/dialog.scss (1)
4-5: Theme import aligns dialog with global stylingDialog uses several
--mdc-theme-*variables; importinglime-themeis the right move.src/components/collapsible-section/collapsible-section.scss (1)
1-1: Document side-effect oflime-themeThe new import is fine, but please add a brief comment (or use
as *) to show that it is intentionally side-effect-only and not forgotten dead code.⛔ Skipped due to learnings
Learnt from: adrianschmidt PR: Lundalogik/lime-elements#3530 File: src/components/text-editor/examples/text-editor-composite.tsx:4-7 Timestamp: 2025-04-17T09:39:36.254Z Learning: For lime-elements, example files should import types from the public API using '@limetech/lime-elements' rather than defining duplicate types locally. This includes types like `EditorUiType` which are part of the component's public API.Learnt from: adrianschmidt PR: Lundalogik/lime-elements#3464 File: src/components/text-editor/prosemirror-adapter/plugins/image/inserter.ts:1-11 Timestamp: 2025-03-04T14:27:29.714Z Learning: In example components (typically found in `src/components/*/examples/`), imports of lime-elements exports should use `@limetech/lime-elements` instead of relative paths. This is because example components aren't included in type declarations and are used in documentation to show developers how to properly use lime-elements components.Learnt from: Kiarokh PR: Lundalogik/lime-elements#3530 File: src/components/text-editor/examples/text-editor-composite.tsx:4-7 Timestamp: 2025-04-16T14:14:18.253Z Learning: For lime-elements, example files should be self-contained and avoid importing internal implementation details. Example files should only import public exports from '@limetech/lime-elements' or use relative imports for other files within the examples folder. Duplicating simple type definitions in example files is preferred over importing internal types.Learnt from: Kiarokh PR: Lundalogik/lime-elements#3529 File: src/components/lime-ai-avatar/lime-ai-avatar.scss:1-3 Timestamp: 2025-04-25T14:23:56.018Z Learning: In the lime-elements repository, CSS custom properties prefixed with `--lime-` are considered internal implementation details and should not be documented in JSDoc comments, while other custom properties should be documented as they are part of the public API.Learnt from: Kiarokh PR: Lundalogik/lime-elements#3530 File: src/components/text-editor/examples/text-editor-composite.tsx:4-7 Timestamp: 2025-04-16T14:14:18.253Z Learning: For lime-elements, example files should be self-contained and avoid importing internal implementation details. This includes not importing types from internal files like '../types.ts', especially those marked with @beta. Duplicating simple type definitions in example files is preferred over importing internal types that may change.Learnt from: adrianschmidt PR: Lundalogik/lime-elements#3464 File: src/components/text-editor/prosemirror-adapter/plugins/image/inserter.ts:1-11 Timestamp: 2025-03-04T13:48:44.712Z Learning: The lime-elements codebase must use relative imports (even with multiple "../") rather than alias imports or re-exports because they export types to `<repo-root>/dist/types`. Using non-relative imports breaks type generation as import paths from generated type files point to full .ts files rather than .d.ts files.Learnt from: Kiarokh PR: Lundalogik/lime-elements#3529 File: src/components/lime-ai-avatar/lime-ai-avatar.scss:24-28 Timestamp: 2025-04-25T14:22:02.157Z Learning: In lime-elements, CSS custom properties follow a specific naming convention: 1. Internal use variables (not for consumers) are prefixed with `--limel-component-name-` 2. External use variables (intended for consumers) are prefixed with `--component-name-` Variables documented with JSDoc comments are typically meant for external use.Learnt from: Kiarokh PR: Lundalogik/lime-elements#3518 File: src/components/notched-outline/examples/notched-outline-basic.scss:11-22 Timestamp: 2025-04-14T10:01:18.721Z Learning: Examples in Lime Elements use Shadow DOM (with `shadow: true` in the component decorator) for style encapsulation, making additional class-based selectors unnecessary. This ensures styles are automatically scoped to each component without leaking to the rest of the application.Learnt from: Kiarokh PR: Lundalogik/lime-elements#3529 File: src/components/lime-ai-avatar/lime-ai-avatar.scss:96-122 Timestamp: 2025-04-25T14:18:07.755Z Learning: In Lime Elements components that use Shadow DOM (with `shadow: true` in the component decorator), keyframe animation names don't need to be namespaced as they are automatically scoped to the component and won't collide with animations from other components.Learnt from: Kiarokh PR: Lundalogik/lime-elements#3464 File: src/components/text-editor/prosemirror-adapter/plugins/image/view.scss:14-17 Timestamp: 2025-03-11T13:31:46.958Z Learning: Lime Elements generally does not support unreasonably old browsers, so modern CSS properties like `scale` that have good support in current browsers are preferred over older alternatives.src/components/date-picker/flatpickr-adapter/flatpickr-adapter.scss (1)
1-1: Import location looks goodThe new
@use '../../../style/internal/lime-theme';is correctly pathed (three..levels up from the adapter folder) and is placed before any rules that rely on theme tokens.
No further action needed here.src/components/tab-bar/tab-bar.scss (1)
1-1: Theme hook-up verifiedAdding the Lime theme import gives the component access to the MDC theme custom properties used later in the file (
var(--mdc-theme-primary)etc.).
Everything compiles fine.src/components/checkbox/checkbox.scss (1)
1-1: Theme import OKNothing to add; the extra
@usehas no side-effects beyond exposing theme tokens.src/components/form/form.scss (1)
1-2: Ordering nitpick
lime-typographydepends on MDC typography mixins and, indirectly, on the theme. Keeping@use '../../style/internal/lime-typography';after the theme import (as done) is correct.
No issues spotted.src/components/banner/banner.scss (1)
1-2: Theme & shared variables import approvedBoth imports are correctly pathed and required for
$lime-banner-height.src/global/core-styles.scss (1)
3-3: Confirm that the new theme import does not introduce duplicate CSS output
lime-theme.scssalready injects thetheme-color-variablesmixin inside every component’s:host.
Becausecore-styles.scssalso calls the same mixin for:root, we now have two almost-identical sets of CSS custom properties (one global, one per-component).
That’s probably what you want, but please double-check the compiled CSS size to make sure the duplication is acceptable.src/style/internal/lime-typography.scss (1)
12-79: Potentially large default CSS from MDC typographyYou override the MDC typography maps but still
@forward '@material/typography'without disabling its default CSS output ($exclude-stylesor similar).
If MDC v11 still emits base styles on forward, every component that@uses this file will bundle them, inflating bundle size.
Consider:@use '@material/typography' with ( $styles-headline1: …, // … $output-css: false // <─ if supported );src/style/internal/lime-theme.scss (1)
14-22: Accessibility: verify contrast between$secondaryand$on-secondary
$secondaryisbrand-colors.$lime-dark-grey(dark grey) and$on-secondaryis hard-coded#fff.
White on dark grey is usually fine, but please run WCAG contrast checks for the exact grey to ensure AA compliance.
Comment on lines
+1
to
+11
| $lime-deep-red: #f05750; | ||
| $lime-red: #ff7043; | ||
| $lime-orange: #ffb03b; | ||
| $lime-yellow: #ffcf3d; | ||
| $lime-green: #66bb6a; | ||
| $lime-turquoise: #26a69a; | ||
| $lime-blue: #29b6f6; | ||
| $lime-dark-blue: #57879f; | ||
| $lime-magenta: #ff3195; | ||
| $lime-light-grey: #adadad; | ||
| $lime-dark-grey: #575756; |
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Consider grouping brand colours in a map for future theming
Individual variables work, but an exported map (e.g. $lime-brand-colors: (...)) would let downstream code iterate or merge them into other colour systems without manual list maintenance.
🤖 Prompt for AI Agents
In src/style/brand-colors.scss lines 1 to 11, the brand color variables are
defined individually, which limits flexibility for theming. Refactor by grouping
these color variables into a single SCSS map named $lime-brand-colors. This map
should associate descriptive keys with each color value, enabling easier
iteration and merging in downstream stylesheets.
| @@ -1,4 +1,5 @@ | |||
| @use '../../style/functions'; | |||
| @use '../../style/internal/lime-theme'; | |||
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Silence the unused-namespace warning
lime-theme is imported for its side-effects only. Add an alias of as * to stop stylelint/Sass from flagging it as unused:
-@use '../../style/internal/lime-theme';
+@use '../../style/internal/lime-theme' as *;📝 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.
Suggested change
| @use '../../style/internal/lime-theme'; | |
| @use '../../style/internal/lime-theme' as *; |
🤖 Prompt for AI Agents
In src/components/badge/badge.scss at line 2, the import of 'lime-theme' is
flagged as an unused namespace by stylelint/Sass because it is imported only for
side-effects. To fix this, modify the import statement to use 'as *' alias,
which tells Sass to import the module for side-effects only and suppresses the
unused-namespace warning.
| @@ -1,3 +1,4 @@ | |||
| @use '../../style/internal/variables'; | |||
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Avoid mixing @use with legacy @import in the same file
@import is deprecated in Dart Sass. Migrating ui-controls.scss (and other partials) to @use/@forward keeps the style pipeline modern and avoids future breaking changes.
🤖 Prompt for AI Agents
In src/components/file-viewer/file-viewer.scss at line 1, avoid mixing the
modern `@use` rule with legacy `@import` statements in the same file. To fix
this, refactor any `@import` statements in this file and its partials like
`ui-controls.scss` to use `@use` or `@forward` instead, ensuring the entire
style pipeline uses the modern Sass module system and avoids deprecated syntax.
| @@ -1,5 +1,6 @@ | |||
| @use '../../../style/mixins'; | |||
| @use '../../../style/functions'; | |||
| @use '../../../style/internal/variables'; | |||
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Same note on @import deprecation
This file now uses @use for new modules but still relies on @import at the end. Worth planning a gradual migration to @use/@forward for consistency and future Sass compatibility.
🤖 Prompt for AI Agents
In src/components/progress-flow/progress-flow-item/progress-flow-item.scss at
line 3, the file uses the new `@use` syntax but still has legacy `@import`
statements later. To fix this, gradually replace all `@import` statements with
`@use` or `@forward` where appropriate, ensuring consistent and future-proof
Sass module usage throughout the file.
Comment on lines
1
to
7
| @use '../../style/functions'; | ||
| @use '../../style/mixins'; | ||
|
|
||
| @use '../../style/internal/lime-theme'; | ||
| @use '../checkbox/checkbox.scss'; | ||
|
|
||
| @use '@material/list'; |
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Minor duplication: checkbox.scss pulled twice
This file now has both
@use '../checkbox/checkbox.scss'; (line 5) and later @import '../checkbox/checkbox.scss'; (line 289).
Having the same stylesheet loaded via two mechanisms can bloat the final bundle and cause style-order quirks. Recommend removing one of them (prefer @use).
-@import '../checkbox/checkbox.scss';📝 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.
Suggested change
| @use '../../style/functions'; | |
| @use '../../style/mixins'; | |
| @use '../../style/internal/lime-theme'; | |
| @use '../checkbox/checkbox.scss'; | |
| @use '@material/list'; | |
| -@import '../checkbox/checkbox.scss'; |
🤖 Prompt for AI Agents
In src/components/list/list.scss between lines 1 and 7, the stylesheet
'../checkbox/checkbox.scss' is imported twice using both '@use' and '@import'
(the latter around line 289). To avoid duplication and potential style
conflicts, remove the '@import' statement at line 289 and keep only the '@use'
statement at line 5, ensuring consistent and optimized stylesheet loading.
Comment on lines
+4
to
+5
| @use '../../style/internal/lime-theme'; | ||
|
|
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Side-effect import: add explanation or wildcard
Same comment as for other files: the new lime-theme module is imported but its API isn’t referenced. Importing with as * and/or adding a comment will make the side-effect clearer and silence “unused namespace” lint rules.
-@use '../../style/internal/lime-theme';
+// Needed to register MDC color/typography via lime-theme side-effects
+@use '../../style/internal/lime-theme' as *;🤖 Prompt for AI Agents
In src/components/button/button.scss around lines 4 to 5, the lime-theme module
is imported but its API is not referenced, causing unclear side-effect imports
and lint warnings. Modify the import statement to use a wildcard import (e.g.,
@use '../../style/internal/lime-theme' as *;) or add a comment explaining the
side-effect purpose of the import to clarify intent and prevent unused namespace
lint errors.
Comment on lines
+6
to
+7
| @use '../../style/internal/lime-theme'; | ||
|
|
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Redundant import
shared_input-select-picker already @uses lime-theme, so importing it again here is duplicate work (Sass de-dupes, but the line adds noise).
-@use '../../style/internal/lime-theme';Unless you plan to reference lime-theme. directly in this file, consider removing the extra import.
📝 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.
Suggested change
| @use '../../style/internal/lime-theme'; |
🤖 Prompt for AI Agents
In src/components/input-field/input-field.scss around lines 6 to 7, the file
redundantly imports 'lime-theme' which is already imported by
'shared_input-select-picker'. Remove the '@use' statement for 'lime-theme' here
unless you need to reference 'lime-theme.' directly in this file to reduce
unnecessary imports and clean up the code.
Comment on lines
+14
to
+15
| @include lime-typography.core-styles; | ||
|
|
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Potential duplicate global typography rules
@include lime-typography.core-styles; injects global .mdc-typography-… classes. Because almost every component now includes the same mixin, we’ll end up emitting identical global rules once per component bundle, bloating size.
If you intend these rules to be global only once, consider:
-@include lime-typography.core-styles;
+// Inject only once at a central place (e.g., style/_global.scss)
+//@include lime-typography.core-styles;🤖 Prompt for AI Agents
In src/components/form/form.scss around lines 14 to 15, the use of @include
lime-typography.core-styles injects global typography classes repeatedly in each
component, causing duplicate CSS and increased bundle size. To fix this, remove
this mixin from individual component styles and instead include it once in a
global or shared stylesheet that is imported only once in the application,
ensuring the global typography rules are emitted a single time.
Comment on lines
1
to
5
| @use '../../style/functions'; | ||
| @use '../../style/internal/shared_input-select-picker'; | ||
| @use '../../style/internal/lime-theme'; | ||
| @use '../../style/internal/lime-typography'; | ||
|
|
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Import order – keep shared helpers first
Minor style nit: keep generic helpers (functions, shared_input-select-picker) before design-system imports (lime-theme, lime-typography) to make intent clearer and avoid accidental circular deps.
🤖 Prompt for AI Agents
In src/components/switch/switch.scss lines 1 to 5, reorder the import statements
so that generic helper imports like 'functions' and 'shared_input-select-picker'
come before design-system imports such as 'lime-theme' and 'lime-typography'.
This clarifies intent and helps prevent circular dependencies.
Comment on lines
+47
to
+49
| :host { | ||
| @include theme-color-variables.theme-color-variables; | ||
| } |
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Scoped vs global variables – is both really needed?
core-styles.scss exposes the palette on :root, and this file re-exposes the same set on each component’s :host. Unless components are rendered outside the main document (e.g. in portals/iframes), keeping only one of them should suffice.
🤖 Prompt for AI Agents
In src/style/internal/lime-theme.scss around lines 47 to 49, the theme color
variables are being included on each component's :host, which duplicates the
global palette already exposed on :root in core-styles.scss. To fix this, remove
the inclusion of theme-color-variables from :host here and rely solely on the
global variables defined on :root, unless there is a specific need for scoped
variables in components rendered outside the main document.
|
🎉 This PR is included in version 38.19.3 🎉 The release is available on: Your semantic-release bot 📦🚀 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary by CodeRabbit
New Features
Style
fix: Lundalogik/crm-client#180
Review:
Browsers tested:
(Check any that applies, it's ok to leave boxes unchecked if testing something didn't seem relevant.)
Windows:
Linux:
macOS:
Mobile: