Merge pull request 'Fix/#42 add hot reload in storybook for stencil' (#43) from fix/#42-add-hot-reload-in-storybook-for-stencil into dev

Reviewed-on: #43

.changeset/ten-rules-bet.md

@@ -1,5 +0,0 @@
----
-'luna-charts': minor
----
-
-Establish the initial project foundation with architecture, documentation, governance, and development tooling.

.gitea/workflows/quality-gate.yml

@@ -87,4 +87,4 @@ jobs:
 
       - name: Run component tests (Playwright)
         working-directory: packages/luna-charts
-        run: pnpm test:browser
+        run: pnpm test:browser --passWithNoTests

.prettierrc.json

@@ -2,6 +2,5 @@
   "singleQuote": true,
   "semi": true,
   "trailingComma": "es5",
-  "printWidth": 100,
+  "printWidth": 100
-    "bracketSameLine": true
 }

Dockerfile.test

@@ -18,4 +18,4 @@ WORKDIR /app/packages/luna-charts
 
 RUN pnpm add -D @rolldown/binding-linux-x64-gnu
 
-CMD ["pnpm", "test:browser"]
+CMD ["pnpm", "test:browser", "--", "--passWithNoTests"]

README.md

@@ -2,7 +2,7 @@
 
 LUNA Charts is a reusable, developer-friendly charting library designed to make accessible, WCAG-oriented data visualization the default rather than an afterthought.
 
-> **Project status:** Groundwork phase. Core architecture and tooling are in place; production-ready chart components (starting with `BarChart`) are still in development. See the [Roadmap](./docs/src/content/docs/getting-started/roadmap.mdx) for details.
+> **Project status:** Working on First Proof of Concept v0.3.0 phase. This milestone focuses on validating the core technical and accessibility assumptions of the library through a first working implementation. The goal is to prove that the chosen architecture (SVG rendering, Web Components, accessibility-first approach) actually works in practice before committing to a broader component set. See the [Roadmap](./docs/src/content/docs/getting-started/roadmap.mdx) for details.
 
 ## Preface & Repository Mirror Notice
 
@@ -17,7 +17,7 @@ Please be aware of our repository structure:
 Most charting libraries treat accessibility as an add-on. LUNA Charts builds it in from the start:
 
 * **Accessible by default** — components are designed and tested against WCAG guidance from day one, not patched in afterward
-* **Framework-agnostic** — built as standard Web Components (Stencil), usable in React, Vue, Angular, Svelte, or plain HTML
+* **Framework-agnostic** — built as standard Web Components (Stencil), usable in React, Vue or Angular.
 * **SVG-based rendering** — inspectable, stylable, and screen-reader-friendly output instead of an opaque canvas
 
 ## Tech Stack
@@ -93,6 +93,7 @@ pnpm install
 | `pnpm run format` | Run the formatter to automatically fix code style issues |
 | `pnpm run test:browser` | Run browser tests (only works inside the `packages/luna-charts` directory) |
 | `pnpm run storybook` | Start the storybook documentation |
+| `pnpm run stencil:dev` | Runs the Stencil development server with live-reloading for the `luna-charts package inside the monorepo. |
 
 Component and browser tests run inside Docker (`docker-compose.test.yaml`), based on the same `Dockerfile.test` used to build the image CI tests against, to guarantee a reproducible browser environment — you don't need Playwright browsers installed locally. Locally this image is built on demand; in CI a prebuilt version of the same image is pulled directly (see [ADR-0002](./docs/src/content/docs/architecture/adr/000200-technology-stack.mdx) and the [Technology Architecture](./docs/src/content/docs/architecture/adm/technology-architecture.mdx#66-test-execution-environment) doc for details).
 
@@ -104,4 +105,4 @@ Component and browser tests run inside Docker (`docker-compose.test.yaml`), base
 
 ## License
 
-LUNA Charts is licensed under the [GNU Lesser General Public License v3.0 (LGPL-3.0)](./LICENSE).
+LUNA Charts is licensed under the [GNU Lesser General Public License v3.0 (LGPL-3.0)](./LICENSE).

docs/CHANGELOG.md

@@ -0,0 +1,13 @@
+# docs
+
+## 0.2.0
+
+### Minor Changes
+
+- This release introduces the next iteration of LUNA Charts with improvements to the component architecture, development workflow, testing infrastructure, and documentation.
+
+  - Improved component development and project structure
+  - Enhanced component testing infrastructure
+  - Improved CI/CD test handling, including projects without test files
+  - Updated and extended project documentation
+  - Various improvements and fixes across the library

docs/package.json

@@ -1,7 +1,7 @@
 {
   "name": "docs",
   "type": "module",
-  "version": "0.0.1",
+  "version": "0.2.0",
   "scripts": {
     "dev": "astro dev",
     "start": "astro dev",

docs/src/content/docs/architecture/adr/000600-declarative-component-api.mdx

@@ -0,0 +1,111 @@
+---
+title: "ADR-000600: Declarative Component API"
+description: "LUNA Charts exposes chart functionality through a strongly typed, component-based declarative API."
+---
+
+* **Status:** Accepted
+* **Date:** 2026-08-31
+* **Decision Makers:** LUNA Charts Maintainers
+
+---
+
+## Context
+
+LUNA Charts must provide a developer-facing API that is easy to understand, strongly typed, framework-agnostic, and capable of enforcing accessibility and validation rules consistently.
+
+Several API models were considered, including a pure domain-specific language (DSL), JSON-based configuration, and a component-based API. The architecture also requires a controlled system boundary so that developers provide chart data and configuration without directly interfering with internal processing.
+
+The Information Systems Architecture defines chart-specific components such as `<BarChart />`, `<LineChart />`, and `<PieChart />`, each with its own strongly typed data model. A single controlled entry point is used for developer interaction, while validation, configuration resolution, accessibility enforcement, and rendering remain under the ownership of the library.
+
+---
+
+## Decision Drivers
+
+* Developer Experience
+* Type Safety
+* Framework Agnosticism
+* Accessibility
+* Maintainability
+* Predictable Behavior
+* Clear System Boundaries
+* Simplicity
+
+---
+
+## Considered Alternatives
+
+| Alternative | Description |
+| ----------- | ----------- |
+| Component-based declarative API | Developers configure charts through strongly typed chart components and their properties. |
+| JSON-based API | Developers provide chart definitions as JSON objects that are interpreted by the library. |
+| Pure DSL | A dedicated textual or configuration language is used to describe charts. |
+| Imperative API | Developers directly invoke rendering and processing operations. |
+
+The component-based declarative API was selected because it provides a natural developer experience, strong TypeScript integration, and a clear boundary between public inputs and internal processing. JSON and pure DSL approaches would require an additional abstraction layer and provide less natural integration with component-based frontend ecosystems. An imperative API would expose more implementation details and weaken the controlled processing model.
+
+---
+
+## Decision
+
+LUNA Charts uses a **component-based declarative API** as its primary developer interaction model.
+
+Developers interact with chart-specific components such as:
+
+* `<BarChart />`
+* `<LineChart />`
+* `<PieChart />`
+
+Each chart component exposes a strongly typed data and configuration model.
+
+The public API is the controlled entry point into the library. Developers provide structured data and configuration, while the internal processing pipeline remains under the control of LUNA Charts.
+
+---
+
+## Rationale
+
+A component-based declarative API aligns the developer experience with modern web component and framework ecosystems while allowing TypeScript to express valid data and configuration structures.
+
+The model also supports LUNA Charts' architectural goals:
+
+* Developers describe the desired chart rather than controlling rendering steps.
+* Type-safe contracts make invalid inputs more explicit.
+* Internal validation and accessibility enforcement remain centrally controlled.
+* The same conceptual API can be consumed through framework-specific integrations.
+* The API remains predictable and maintainable as additional chart types are introduced.
+
+---
+
+## Consequences
+
+### Positive
+
+* Clear and approachable developer API.
+* Strong TypeScript integration and type safety.
+* Declarative usage reduces exposure to internal implementation details.
+* Consistent integration model across supported frontend ecosystems.
+* Internal accessibility and validation rules remain centrally enforceable.
+* New chart types can follow the same API pattern.
+
+### Negative
+
+* Developers have less low-level control over internal processing.
+* Custom behavior outside the defined API requires changes by the LUNA Charts maintainers.
+* Strong API constraints can make unusual use cases harder to support.
+* Each chart type requires a dedicated typed model.
+
+---
+
+## Related TOGAF Phases
+
+* Architecture Vision (Phase A)
+* Business Architecture (Phase B)
+* Information Systems Architecture (Phase C)
+* Technology Architecture (Phase D)
+
+---
+
+## References
+
+* [Information Systems Architecture](../adm/information-systems-architecture/)
+* [Technology Architecture](../adm/technology-architecture/)
+* [ADR-000300 – Web Components as Public API](./000300-web-components-as-public-api/)

docs/src/content/docs/architecture/adr/000700-no-plugin-or-extension-system.mdx

@@ -0,0 +1,102 @@
+---
+title: "ADR-0007000: No Plugin or Extension System"
+description: "LUNA Charts does not provide a consumer-facing plugin or extension mechanism."
+---
+
+* **Status:** Accepted
+* **Date:** 2026-08-31
+* **Decision Makers:** LUNA Charts Maintainers
+
+---
+
+## Context
+
+LUNA Charts is designed as an opinionated charting library with a controlled internal processing pipeline. Accessibility, validation, configuration resolution, and rendering are library-owned responsibilities.
+
+An extension mechanism could allow consumers to modify internal behavior or add functionality without changing the core library. However, unrestricted extensibility could also introduce inconsistent behavior, weaken accessibility guarantees, and increase architectural and maintenance complexity.
+
+The Information Systems Architecture therefore defines LUNA Charts as a closed system with a strict input boundary and no external plugin or extension mechanism.
+
+---
+
+## Decision Drivers
+
+* Accessibility
+* Maintainability
+* Predictable Behavior
+* Simplicity
+* Quality Control
+* Security
+* Developer Experience
+
+---
+
+## Considered Alternatives
+
+| Alternative | Description |
+| ----------- | ----------- |
+| No plugin or extension system | Consumers use only the public API provided by LUNA Charts. |
+| Consumer plugin system | Consumers can register plugins that modify or extend library behavior. |
+| Extension hooks | Consumers can inject custom logic into selected processing stages. |
+| Fully extensible architecture | Internal layers and chart types can be extended directly by consumers. |
+
+The no-plugin approach was selected because the library's accessibility and rendering behavior must remain centrally controlled. Plugin systems and extension hooks would increase the number of execution paths that must be validated and supported.
+
+---
+
+## Decision
+
+LUNA Charts **does not provide a consumer-facing plugin or extension system**.
+
+Consumers interact with the library exclusively through its defined public API. Internal processing stages cannot be replaced, intercepted, or extended by consumers.
+
+New chart types, accessibility behavior, rendering capabilities, and other architectural functionality are implemented and maintained within the LUNA Charts project itself.
+
+---
+
+## Rationale
+
+LUNA Charts is intentionally opinionated. Its value depends not only on providing chart visualizations but also on providing predictable and accessible implementations.
+
+Allowing consumers to modify internal behavior would make it harder to guarantee consistent accessibility and quality. A closed architecture keeps the processing pipeline deterministic and allows maintainers to evolve the implementation under a single quality and accessibility model.
+
+This decision also avoids the additional API surface, compatibility requirements, documentation burden, and support obligations associated with a plugin ecosystem.
+
+---
+
+## Consequences
+
+### Positive
+
+* Centralized control over accessibility behavior.
+* Predictable and deterministic processing.
+* Smaller public API surface.
+* Lower maintenance and compatibility burden.
+* Easier quality assurance and testing.
+* No plugin ecosystem needs to be designed or maintained.
+* Reduced risk that consumer extensions bypass architectural safeguards.
+
+### Negative
+
+* Consumers cannot add custom processing stages.
+* Consumers cannot introduce custom chart types through plugins.
+* Unusual use cases may require changes to LUNA Charts itself.
+* The architecture places more responsibility on the maintainers to evolve the library.
+
+---
+
+## Related TOGAF Phases
+
+* Architecture Vision (Phase A)
+* Business Architecture (Phase B)
+* Information Systems Architecture (Phase C)
+* Technology Architecture (Phase D)
+
+---
+
+## References
+
+* [Business Architecture](../adm/business-architecture/)
+* [Information Systems Architecture](../adm/information-systems-architecture/)
+* [Technology Architecture](../adm/technology-architecture/)
+* [ADR-000500 – Accessibility as a Cross-Cutting Concern](./000500-accessibility-as-a-cross-cutting-concern/)

docs/src/content/docs/architecture/adr/000800-single-package-distribution-model.mdx

@@ -0,0 +1,101 @@
+---
+title: "ADR-000800: Single-Package Distribution Model"
+description: "LUNA Charts is distributed as one unified package rather than separate packages per chart type or internal module."
+---
+
+* **Status:** Accepted
+* **Date:** 2026-08-31
+* **Decision Makers:** LUNA Charts Maintainers
+
+---
+
+## Context
+
+LUNA Charts is developed as a monorepo and contains multiple internal modules and chart types. The repository structure must remain flexible for implementation while the public distribution model should remain simple for consumers.
+
+The architecture distinguishes between internal implementation boundaries and the public package boundary. Chart types such as BarChart, LineChart, and PieChart are not intended to become independent npm packages.
+
+LUNA Charts is intended to be consumed as one coherent, accessibility-focused library.
+
+---
+
+## Decision Drivers
+
+* Developer Experience
+* Simplicity
+* Accessibility
+* Maintainability
+* Consistent API Behavior
+* Framework Agnosticism
+* Release Management
+* Reduced Package Fragmentation
+
+---
+
+## Considered Alternatives
+
+| Alternative | Description |
+| ----------- | ----------- |
+| Single package | All public chart functionality is distributed through one LUNA Charts package. |
+| Package per chart type | Each chart type is published as an independent npm package. |
+| Package per internal module | Internal modules such as core and charts are independently published. |
+| Monorepo with multiple public packages | The repository remains a monorepo while several independently versioned packages are published. |
+
+The single-package model was selected because the library is intended to provide one coherent developer experience and one consistent accessibility model. Publishing chart types or internal modules separately would increase package, versioning, dependency, and compatibility complexity.
+
+---
+
+## Decision
+
+LUNA Charts is distributed as **one unified public npm package**.
+
+Chart types, core functionality, accessibility mechanisms, and other implementation modules remain internal parts of the distribution and are not published as separate public packages.
+
+Framework-specific integrations generated from the Stencil-based implementation are considered part of the overall LUNA Charts distribution model rather than independent chart packages.
+
+---
+
+## Rationale
+
+A single package gives consumers one installation target and one coherent version of the library.
+
+It also supports the project's accessibility-first architecture. Accessibility enforcement, validation, rendering, and chart functionality can evolve together without requiring consumers to coordinate compatible versions of several packages.
+
+The monorepo therefore provides internal organizational and architectural separation without exposing unnecessary package fragmentation to consumers.
+
+---
+
+## Consequences
+
+### Positive
+
+* Simple installation and onboarding.
+* One public version and release lifecycle.
+* Consistent accessibility and API behavior across chart types.
+* No dependency coordination between separate chart packages.
+* Easier documentation and support.
+* Internal modules can evolve without becoming public package contracts.
+
+### Negative
+
+* Consumers cannot install only an individual chart package.
+* The public package may contain functionality that a particular consumer does not use.
+* A change in one part of the library may require a release of the unified package.
+* Package-level boundaries cannot be used to independently version individual chart types.
+
+---
+
+## Related TOGAF Phases
+
+* Architecture Vision (Phase A)
+* Business Architecture (Phase B)
+* Information Systems Architecture (Phase C)
+* Technology Architecture (Phase D)
+
+---
+
+## References
+
+* [Repository Structure](./000100-repository-structure/)
+* [Technology Architecture](../adm/technology-architecture/)
+* [Information Systems Architecture](../adm/information-systems-architecture/)

docs/src/content/docs/architecture/adr/000900-multi-layer-testing-strategy.mdx

@@ -0,0 +1,116 @@
+---
+title: "ADR-000900: Multi-Layer Testing Strategy"
+description: "LUNA Charts uses multiple complementary quality assurance layers with automated release gates."
+---
+
+* **Status:** Accepted
+* **Date:** 2026-08-31
+* **Decision Makers:** LUNA Charts Maintainers
+
+---
+
+## Context
+
+LUNA Charts is an accessibility-focused charting library whose output must be correct, stable, and usable across supported environments.
+
+No single testing technique can adequately validate the library. Functional correctness, accessibility constraints, DOM and SVG structure, visual stability, code quality, and real-world usability require different forms of verification.
+
+The Technology Architecture therefore defines a multi-layer quality assurance model covering functional tests, accessibility tests, linting, visual regression testing, and usability testing. Automated checks are combined with release gating so that defined quality requirements are evaluated before releases.
+
+---
+
+## Decision Drivers
+
+* Accessibility
+* Reliability
+* Visual Stability
+* Maintainability
+* Developer Experience
+* Reproducibility
+* Release Quality
+* Automation
+
+---
+
+## Considered Alternatives
+
+| Alternative | Description |
+| ----------- | ----------- |
+| Multi-layer testing strategy | Multiple complementary test and quality layers are combined into release gates. |
+| Unit tests only | Functional behavior is validated primarily through unit tests. |
+| End-to-end tests only | Browser-based tests are used as the primary validation mechanism. |
+| Manual testing only | Quality is validated through manual verification before releases. |
+
+The multi-layer approach was selected because each alternative alone leaves important quality risks uncovered. Unit tests do not sufficiently validate browser behavior or accessibility, while browser tests alone are less efficient for isolated logic. Manual testing remains valuable for usability but cannot provide sufficient automated regression coverage.
+
+---
+
+## Decision
+
+LUNA Charts uses a **multi-layer testing and quality assurance strategy**.
+
+The strategy includes:
+
+1. **Functional testing** for core logic and processing behavior.
+2. **Accessibility testing** for machine-verifiable accessibility requirements and ARIA structure.
+3. **Code quality checks** including linting and formatting-related quality controls.
+4. **Visual regression testing** to detect unintended visual and structural changes.
+5. **Usability testing** for relevant minor and major releases and significant user-facing changes.
+6. **Release gates** that prevent releases when required automated quality checks fail.
+
+Browser-based tests use a reproducible test execution environment so that local and CI execution can use a controlled environment.
+
+---
+
+## Rationale
+
+LUNA Charts has accessibility and visual output as central quality attributes. These cannot be reliably validated through unit tests alone.
+
+A layered strategy assigns each quality concern to an appropriate verification mechanism:
+
+* Unit tests provide fast feedback for logic.
+* Accessibility tests validate machine-verifiable accessibility constraints.
+* Linting protects code and architectural consistency.
+* Visual regression tests protect rendered output and relevant DOM structure.
+* Usability testing evaluates aspects that cannot be reliably automated.
+* Release gates ensure required automated checks are completed before distribution.
+
+The approach balances fast developer feedback with stronger release confidence.
+
+---
+
+## Consequences
+
+### Positive
+
+* Higher confidence in functional correctness.
+* Accessibility becomes part of the quality process rather than a final manual check.
+* Visual regressions can be detected automatically.
+* Release quality is enforced consistently.
+* Different test types can remain focused on the problems they are best suited to detect.
+* Reproducible browser test execution reduces environment-related differences between developers and CI.
+
+### Negative
+
+* More tooling and infrastructure must be maintained.
+* Test execution can require more time and resources than unit tests alone.
+* Visual regression tests require maintenance when intentional visual changes occur.
+* Usability testing introduces manual effort.
+* Release gates can delay releases when infrastructure or tests fail.
+
+---
+
+## Related TOGAF Phases
+
+* Architecture Vision (Phase A)
+* Technology Architecture (Phase D)
+* Opportunities and Solutions (Phase E)
+* Implementation Governance (Phase G)
+
+---
+
+## References
+
+* [Technology Architecture](../adm/technology-architecture/)
+* [Testing and Quality Strategy](../adm/technology-architecture/#6-testing--quality-strategy)
+* [ADR-000500 – Accessibility as a Cross-Cutting Concern](./000500-accessibility-as-a-cross-cutting-concern/)

docs/src/content/docs/getting-started/roadmap.mdx

@@ -19,8 +19,8 @@ Instead of implementing features immediately, the project establishes a solid ar
 
 Completed work includes:
 
-- **Repository structure:** Standardized layout for code, configurations, and assets. 
+- **Repository structure:** Standardized layout for code, configurations, and assets.
-- **Development workflow: Definition of branching strategies, commit rules, and review processes. 
+- \*\*Development workflow: Definition of branching strategies, commit rules, and review processes.
 - **Architecture documentation (TOGAF ADM):** Architecture framework set up according to the TOGAF standard.
 - **Architecture Decision Records (ADRs 1-5):** System established for transparent documentation of architectural decisions.
 - **Project governance:** Defined roles, responsibilities, and decision-making processes.
@@ -32,40 +32,46 @@ At this stage, no production-ready chart components are available.
 
 ---
 
-## Current Status ⏳
+<details>
+  <summary>
+    Completed Foundation v0.2.0
+  </summary>
+  This milestone focuses on setting up the technical core of the component library. The goal is to build an automated, 
+  testable, and documented environment for efficient StencilJS component development.
 
-### Foundation v0.2.0
+  This milestone focuses on setting up the technical core of the component library. The goal is to build an automated,
+  testable, and documented environment for efficient StencilJS component development.
 
-This milestone focuses on setting up the technical core of the component library. The goal is to build an automated, 
+  - **Create the initial StencilJS library:** Initialize the codebase and core configurations for the web component engine.
-testable, and documented environment for efficient StencilJS component development.
+  - **Establish Storybook for component development:** Set up Storybook as the development environment and isolated playground for component creation.
-
+  - **Configure testing infrastructure:** Configure unit, integration, or visual regression testing frameworks.
-- **Create the initial StencilJS library:** Initialize the codebase and core configurations for the web component engine.
+  - **Configure CI/CD pipeline:** Automate linting, testing, and initial build checks on every repository push or pull request.
-- **Establish Storybook for component development:** Set up Storybook as the development environment and isolated playground for component creation.
+</details>
-- **Configure testing infrastructure:** Configure unit, integration, or visual regression testing frameworks.
-- **Configure CI/CD pipeline:** Automate linting, testing, and initial build checks on every repository push or pull request.
 
 ---
 
-## Upcoming Milestones 🚀
+## Current Status ⏳
 
 ### First Proof of Concept v0.3.0
 
-This milestone focuses on validating the core technical and accessibility assumptions of the library through a first 
+This milestone focuses on validating the core technical and accessibility assumptions of the library through a first
-working implementation. The goal is to prove that the chosen architecture (SVG rendering, Web Components, accessibility-first 
+working implementation. The goal is to prove that the chosen architecture (SVG rendering, Web Components, accessibility-first
 approach) actually works in practice before committing to a broader component set.
 Goals include:
 
 - **SVG rendering:** Implement a first chart component using SVG-based rendering.
 - **Accessibility validation:** Verify WCAG compliance with automated (axe-core) and manual (screen reader) testing.
-- **Framework integration:** Confirm the component works correctly when consumed from at 
+- **Framework integration:** Confirm the component works correctly when consumed from at
-least one external framework (e.g. React or Vue).
+  least one external framework (e.g. React or Vue).
 - **Community feedback:** Share the proof of concept for early feedback before scaling to further components.
 
 ---
 
+## Upcoming Milestones 🚀
+
 ### Minimum Viable Product (MVP) v1.0.0
 
-This milestone marks the first public-ready release. The goal is a stable, documented, 
+This milestone marks the first public-ready release. The goal is a stable, documented,
 and accessible set of chart components that can be safely adopted by external users.
 The MVP focuses on delivering value rather than completeness.
 
@@ -81,7 +87,7 @@ Expected outcomes include:
 
 ### Community Growth
 
-With a stable MVP in place, this milestone shifts focus toward expanding the library's reach, 
+With a stable MVP in place, this milestone shifts focus toward expanding the library's reach,
 capabilities, and contributor base.
 Future work may include:
 

package.json

@@ -1,11 +1,12 @@
 {
   "name": "LUNA-Charts",
-  "version": "1.0.0",
+  "version": "0.2.0",
   "description": "",
   "main": "index.js",
   "scripts": {
     "docs": "pnpm --filter docs run dev",
     "lint": "pnpm --filter luna-charts run lint",
+    "stencil:dev": "pnpm --filter luna-charts exec stencil build --watch",
     "format": "prettier --write .",
     "format:check": "pnpm --filter luna-charts run format:check",
     "changeset": "changeset",

packages/luna-charts/.prettierrc.json

@@ -1,7 +1,6 @@
 {
   "arrowParens": "avoid",
   "bracketSpacing": true,
-  "jsxBracketSameLine": false,
   "jsxSingleQuote": false,
   "quoteProps": "consistent",
   "printWidth": 180,

packages/luna-charts/CHANGELOG.md

@@ -0,0 +1,15 @@
+# luna-charts
+
+## 0.2.0
+
+### Minor Changes
+
+- This release introduces the next iteration of LUNA Charts with improvements to the component architecture, development workflow, testing infrastructure, and documentation.
+
+  - Improved component development and project structure
+  - Enhanced component testing infrastructure
+  - Improved CI/CD test handling, including projects without test files
+  - Updated and extended project documentation
+  - Various improvements and fixes across the library
+
+- 72c49e6: Establish the initial project foundation with architecture, documentation, governance, and development tooling.

packages/luna-charts/custom-elements.json

@@ -1,94 +1,45 @@
 {
-  "timestamp": "2026-08-01T23:02:04",
+  "timestamp": "2026-10-05T16:30:03",
   "compiler": {
     "name": "@stencil/core",
-    "version": "4.43.5",
+    "version": "4.44.2",
     "typescriptVersion": "5.8.3"
   },
   "components": [
     {
-      "filePath": "src/components/my-component/my-component.tsx",
+      "filePath": "src/components/charts/bar-chart/bar-chart.tsx",
       "encapsulation": "shadow",
-      "tag": "my-component",
+      "tag": "bar-chart",
-      "readme": "# my-component\n\n\n",
+      "readme": "# bar-chart\n\n\n",
       "docs": "",
       "docsTags": [],
       "usage": {},
       "props": [
         {
-          "name": "first",
+          "name": "title",
-          "type": "string | undefined",
+          "type": "string",
           "complexType": {
             "original": "string",
-            "resolved": "string | undefined",
+            "resolved": "string",
             "references": {}
           },
           "mutable": false,
-          "attr": "first",
+          "attr": "title",
           "reflectToAttr": false,
-          "docs": "The first name",
+          "docs": "",
-          "docsTags": [],
+          "docsTags": [
+            {
+              "name": "default",
+              "text": "'Hello World'"
+            }
+          ],
+          "default": "'Hello World'",
           "values": [
             {
               "type": "string"
-            },
-            {
-              "type": "undefined"
             }
           ],
-          "optional": true,
+          "optional": false,
-          "required": false,
-          "getter": false,
-          "setter": false
-        },
-        {
-          "name": "last",
-          "type": "string | undefined",
-          "complexType": {
-            "original": "string",
-            "resolved": "string | undefined",
-            "references": {}
-          },
-          "mutable": false,
-          "attr": "last",
-          "reflectToAttr": false,
-          "docs": "The last name",
-          "docsTags": [],
-          "values": [
-            {
-              "type": "string"
-            },
-            {
-              "type": "undefined"
-            }
-          ],
-          "optional": true,
-          "required": false,
-          "getter": false,
-          "setter": false
-        },
-        {
-          "name": "middle",
-          "type": "string | undefined",
-          "complexType": {
-            "original": "string",
-            "resolved": "string | undefined",
-            "references": {}
-          },
-          "mutable": false,
-          "attr": "middle",
-          "reflectToAttr": false,
-          "docs": "The middle name",
-          "docsTags": [],
-          "values": [
-            {
-              "type": "string"
-            },
-            {
-              "type": "undefined"
-            }
-          ],
-          "optional": true,
           "required": false,
           "getter": false,
           "setter": false
@@ -98,7 +49,12 @@
       "events": [],
       "listeners": [],
       "styles": [],
-      "slots": [],
+      "slots": [
+        {
+          "name": "",
+          "docs": "The default slot"
+        }
+      ],
       "parts": [],
       "states": [],
       "dependents": [],
@@ -106,5 +62,11 @@
       "dependencyGraph": {}
     }
   ],
-  "typeLibrary": {}
+  "typeLibrary": {
+    "src/types/index.ts::ChartInfo": {
+      "declaration": "export interface ChartInfo {\n  title: string;\n  description: string;  \n  sourceUrl: string;   \n}",
+      "docstring": "",
+      "path": "src/types/index.ts"
+    }
+  }
 }

packages/luna-charts/package.json

@@ -1,6 +1,6 @@
 {
   "name": "luna-charts",
-  "version": "0.0.1",
+  "version": "0.2.0",
   "description": "Stencil Component Starter",
   "main": "dist/index.cjs.js",
   "module": "dist/index.js",

packages/luna-charts/src/components.d.ts

@@ -5,64 +5,46 @@
  */
 import { HTMLStencilElement, JSXBase } from '@stencil/core/internal';
 export namespace Components {
-  interface MyComponent {
+  interface BarChart {
     /**
-     * The first name
+     * @default 'Hello World'
      */
-    first?: string;
+    title: string;
-    /**
-     * The last name
-     */
-    last?: string;
-    /**
-     * The middle name
-     */
-    middle?: string;
   }
 }
 declare global {
-  interface HTMLMyComponentElement extends Components.MyComponent, HTMLStencilElement {}
+  interface HTMLBarChartElement extends Components.BarChart, HTMLStencilElement {}
-  var HTMLMyComponentElement: {
+  var HTMLBarChartElement: {
-    prototype: HTMLMyComponentElement;
+    prototype: HTMLBarChartElement;
-    new (): HTMLMyComponentElement;
+    new (): HTMLBarChartElement;
   };
   interface HTMLElementTagNameMap {
-    'my-component': HTMLMyComponentElement;
+    'bar-chart': HTMLBarChartElement;
   }
 }
 declare namespace LocalJSX {
-  interface MyComponent {
+  interface BarChart {
     /**
-     * The first name
+     * @default 'Hello World'
      */
-    first?: string;
+    title?: string;
-    /**
-     * The last name
-     */
-    last?: string;
-    /**
-     * The middle name
-     */
-    middle?: string;
   }
 
-  interface MyComponentAttributes {
+  interface BarChartAttributes {
-    first: string;
+    title: string;
-    middle: string;
-    last: string;
   }
 
   interface IntrinsicElements {
-    'my-component': Omit<MyComponent, keyof MyComponentAttributes> & { [K in keyof MyComponent & keyof MyComponentAttributes]?: MyComponent[K] } & {
+    'bar-chart': Omit<BarChart, keyof BarChartAttributes> & { [K in keyof BarChart & keyof BarChartAttributes]?: BarChart[K] } & {
-      [K in keyof MyComponent & keyof MyComponentAttributes as `attr:${K}`]?: MyComponentAttributes[K];
+      [K in keyof BarChart & keyof BarChartAttributes as `attr:${K}`]?: BarChartAttributes[K];
-    } & { [K in keyof MyComponent & keyof MyComponentAttributes as `prop:${K}`]?: MyComponent[K] };
+    } & { [K in keyof BarChart & keyof BarChartAttributes as `prop:${K}`]?: BarChart[K] };
   }
 }
 export { LocalJSX as JSX };
 declare module '@stencil/core' {
   export namespace JSX {
     interface IntrinsicElements {
-      'my-component': LocalJSX.IntrinsicElements['my-component'] & JSXBase.HTMLAttributes<HTMLMyComponentElement>;
+      'bar-chart': LocalJSX.IntrinsicElements['bar-chart'] & JSXBase.HTMLAttributes<HTMLBarChartElement>;
     }
   }
 }

packages/luna-charts/src/components/charts/bar-chart/bar-chart.stories.tsx

@@ -0,0 +1,24 @@
+import type { Meta, StoryObj } from '@stencil/storybook-plugin';
+import { h } from '@stencil/core';
+import { BarChart } from './bar-chart';
+
+const meta: Meta<BarChart> = {
+  title: 'BarChart',
+  component: BarChart,
+  parameters: {
+    layout: 'centered',
+  },
+};
+
+export default meta;
+
+type Story = StoryObj<BarChart>;
+
+export const Primary: Story = {
+  args: {},
+  render: () => <bar-chart title="test" />,
+};
+
+export const Secondary: Story = {
+  args: {},
+};

packages/luna-charts/src/components/charts/bar-chart/bar-chart.tsx

@@ -0,0 +1,18 @@
+import { Component, Host, Prop, h } from '@stencil/core';
+
+@Component({
+  tag: 'bar-chart',
+  styleUrl: 'bar-chart.css',
+  shadow: true,
+})
+export class BarChart {
+  @Prop() title: string = 'Hello World';
+
+  render() {
+    return (
+      <Host>
+        <slot>{this.title}</slot>
+      </Host>
+    );
+  }
+}

packages/luna-charts/src/components/charts/bar-chart/test/bar-chart.e2e.ts

@@ -0,0 +1,12 @@
+import { newE2EPage } from '@stencil/core/testing';
+import { describe, expect, it } from 'vitest';
+
+describe('bar-chart', () => {
+  it('renders', async () => {
+    const page = await newE2EPage();
+    await page.setContent('<bar-chart></bar-chart>');
+
+    const element = await page.find('bar-chart');
+    expect(element).toHaveClass('hydrated');
+  });
+});

packages/luna-charts/src/components/charts/bar-chart/test/bar-chart.spec.tsx

@@ -0,0 +1,19 @@
+import { newSpecPage } from '@stencil/core/testing';
+import { BarChart } from '../bar-chart';
+import { describe, expect, it } from 'vitest';
+
+describe('bar-chart', () => {
+  it('renders', async () => {
+    const page = await newSpecPage({
+      components: [BarChart],
+      html: `<bar-chart></bar-chart>`,
+    });
+    expect(page.root).toEqualHtml(`
+      <bar-chart>
+        <mock:shadow-root>
+          <slot></slot>
+        </mock:shadow-root>
+      </bar-chart>
+    `);
+  });
+});

packages/luna-charts/src/components/my-component/my-component.cmp.test.tsx

@@ -1,37 +0,0 @@
-import { render, h, describe, it, expect } from '@stencil/vitest';
-import { runA11yChecks } from '../../testing/a11y';
-
-describe('my-component', () => {
-  it('renders', async () => {
-    const { root } = await render(<my-component></my-component>);
-    await expect(root).toEqualHtml(`
-      <my-component class="hydrated">
-        <mock:shadow-root>
-          <div>
-            Hello, World! I'm
-          </div>
-        </mock:shadow-root>
-      </my-component>
-    `);
-  });
-
-  it('has no accessibility violations', async () => {
-    const { root } = await render(<my-component></my-component>);
-
-    const results = await runA11yChecks(root);
-    expect(results).toHaveNoA11yViolations();
-  });
-
-  it('renders with values', async () => {
-    const { root } = await render(<my-component first="Stencil" middle="'Don't call me a framework'" last="JS"></my-component>);
-    await expect(root).toEqualHtml(`
-      <my-component class="hydrated">
-        <mock:shadow-root>
-          <div>
-            Hello, World! I'm Stencil 'Don't call me a framework' JS
-          </div>
-        </mock:shadow-root>
-      </my-component>
-    `);
-  });
-});

packages/luna-charts/src/components/my-component/my-component.stories.tsx

@@ -1,41 +0,0 @@
-import type { Meta, StoryObj } from '@stencil/storybook-plugin';
-import { h } from '@stencil/core';
-import { MyComponent } from './my-component';
-
-const meta: Meta<MyComponent> = {
-  title: 'MyComponent',
-  component: MyComponent,
-  parameters: {
-    layout: 'centered',
-  },
-  argTypes: {
-    first: { control: 'text' },
-    last: { control: 'text' },
-    middle: { control: 'text' },
-  },
-  args: { first: 'John', last: 'Doe', middle: 'Michael' },
-};
-
-export default meta;
-
-type Story = StoryObj<MyComponent>;
-
-export const Primary: Story = {
-  args: {
-    first: 'John',
-    last: 'Doe',
-    middle: 'Michael',
-  },
-  render: props => <my-component {...props} />,
-};
-
-/**
- * Storybook story without custom render function
- */
-export const Secondary: Story = {
-  args: {
-    first: 'Jane',
-    last: 'Smith',
-    middle: 'Marie',
-  },
-};

packages/luna-charts/src/components/my-component/my-component.tsx

@@ -1,32 +0,0 @@
-import { Component, Prop, h } from '@stencil/core';
-import { format } from '../../utils/utils';
-
-@Component({
-  tag: 'my-component',
-  styleUrl: 'my-component.css',
-  shadow: true,
-})
-export class MyComponent {
-  /**
-   * The first name
-   */
-  @Prop() first?: string;
-
-  /**
-   * The middle name
-   */
-  @Prop() middle?: string;
-
-  /**
-   * The last name
-   */
-  @Prop() last?: string;
-
-  private getText(): string {
-    return format(this.first, this.middle, this.last);
-  }
-
-  render() {
-    return <div>Hello, World! I'm {this.getText()}</div>;
-  }
-}

packages/luna-charts/src/components/my-component/readme.md

@@ -1,15 +0,0 @@
-# my-component
-
-<!-- Auto Generated Below -->
-
-## Properties
-
-| Property | Attribute | Description     | Type                  | Default     |
-| -------- | --------- | --------------- | --------------------- | ----------- |
-| `first`  | `first`   | The first name  | `string \| undefined` | `undefined` |
-| `last`   | `last`    | The last name   | `string \| undefined` | `undefined` |
-| `middle` | `middle`  | The middle name | `string \| undefined` | `undefined` |
-
----
-
-_Built with [StencilJS](https://stenciljs.com/)_

packages/luna-charts/stencil.config.ts

@@ -12,9 +12,6 @@ export const config: Config = {
       customElementsExportBehavior: 'auto-define-custom-elements',
       externalRuntime: false,
     },
-    {
-      type: 'docs-readme',
-    },
     {
       type: 'www',
       serviceWorker: null, // disable service workers