Added storybook with example in thw preview.tsx

tsconfig.json extends from tsconfig.base.json
renamed tsconfig.base.yaml to tsconfig.base.json
2026-07-12 15:44:12 +02:00 · 2026-07-12 15:43:41 +02:00 · 2026-07-12 15:42:20 +02:00 · 2026-07-12 13:47:25 +02:00 · 2026-07-12 13:43:50 +02:00 · 2026-07-12 12:13:37 +02:00
42 changed files with 6271 additions and 23 deletions
@@ -0,0 +1,8 @@
 # Changesets
 Hello and welcome! This folder has been automatically generated by `@changesets/cli`, a build tool that works
 with multi-package repos, or single-package repos to help you version and publish your code. You can
 find the full documentation for it [in our repository](https://github.com/changesets/changesets).
 We have a quick list of common questions to get you started engaging with this project in
 [our documentation](https://github.com/changesets/changesets/blob/main/docs/common-questions.md).
@@ -0,0 +1,11 @@
 {
  "$schema": "https://unpkg.com/@changesets/config@3.1.4/schema.json",
  "changelog": "@changesets/cli/changelog",
  "commit": false,
  "fixed": [],
  "linked": [],
  "access": "restricted",
  "baseBranch": "dev",
  "updateInternalDependencies": "patch",
  "ignore": ["apps/docs"]
 }
@@ -0,0 +1 @@
 node_modules
@@ -0,0 +1,4 @@
 dist 
 www 
 node_modules 
 .stencil
@@ -0,0 +1,6 @@
 {
  "singleQuote": true,
  "semi": true,
  "trailingComma": "es5",
  "printWidth": 100
 }
@@ -1,4 +1,5 @@
-GNU LESSER GENERAL PUBLIC LICENSE
+# GNU LESSER GENERAL PUBLIC LICENSE
 Version 3, 29 June 2007
 Copyright (C) 2007 Free Software Foundation, Inc. <http://fsf.org/>
@@ -7,7 +8,7 @@ Everyone is permitted to copy and distribute verbatim copies of this license doc
 This version of the GNU Lesser General Public License incorporates the terms and conditions of version 3 of the GNU General Public License, supplemented by the additional permissions listed below.
-0. Additional Definitions.
+0.Additional Definitions.
 As used herein, "this License" refers to version 3 of the GNU Lesser General Public License, and the "GNU GPL" refers to version 3 of the GNU General Public License.
@@ -101,7 +102,7 @@ The precise terms and conditions for copying, distribution and modification foll
 TERMS AND CONDITIONS
-0. Definitions.
+0.Definitions.
 “This License” refers to version 3 of the GNU General Public License.
@@ -132,24 +133,24 @@ The Corresponding Source need not include anything that users can regenerate aut
 The Corresponding Source for a work in source code form is that same work.
-2. Basic Permissions.
+2.Basic Permissions.
 All rights granted under this License are granted for the term of copyright on the Program, and are irrevocable provided the stated conditions are met. This License explicitly affirms your unlimited permission to run the unmodified Program. The output from running a covered work is covered by this License only if the output, given its content, constitutes a covered work. This License acknowledges your rights of fair use or other equivalent, as provided by copyright law.
 You may make, run and propagate covered works that you do not convey, without conditions so long as your license otherwise remains in force. You may convey covered works to others for the sole purpose of having them make modifications exclusively for you, or provide you with facilities for running those works, provided that you comply with the terms of this License in conveying all material for which you do not control copyright. Those thus making or running the covered works for you must do so exclusively on your behalf, under your direction and control, on terms that prohibit them from making any copies of your copyrighted material outside their relationship with you.
 Conveying under any other circumstances is permitted solely under the conditions stated below. Sublicensing is not allowed; section 10 makes it unnecessary.
-3. Protecting Users' Legal Rights From Anti-Circumvention Law.
+3.Protecting Users' Legal Rights From Anti-Circumvention Law.
 No covered work shall be deemed part of an effective technological measure under any applicable law fulfilling obligations under article 11 of the WIPO copyright treaty adopted on 20 December 1996, or similar laws prohibiting or restricting circumvention of such measures.
 When you convey a covered work, you waive any legal power to forbid circumvention of technological measures to the extent such circumvention is effected by exercising rights under this License with respect to the covered work, and you disclaim any intention to limit operation or modification of the work as a means of enforcing, against the work's users, your or third parties' legal rights to forbid circumvention of technological measures.
-4. Conveying Verbatim Copies.
+4.Conveying Verbatim Copies.
 You may convey verbatim copies of the Program's source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice; keep intact all notices stating that this License and any non-permissive terms added in accord with section 7 apply to the code; keep intact all notices of the absence of any warranty; and give all recipients a copy of this License along with the Program.
 You may charge any price or no price for each copy that you convey, and you may offer support or warranty protection for a fee.
-5. Conveying Modified Source Versions.
+5.Conveying Modified Source Versions.
 You may convey a work based on the Program, or the modifications to produce it from the Program, in the form of source code under the terms of section 4, provided that you also meet all of these conditions:
     a) The work must carry prominent notices stating that you modified it, and giving a relevant date.
@@ -162,7 +163,7 @@ You may convey a work based on the Program, or the modifications to produce it f
 A compilation of a covered work with other separate and independent works, which are not by their nature extensions of the covered work, and which are not combined with it such as to form a larger program, in or on a volume of a storage or distribution medium, is called an “aggregate” if the compilation and its resulting copyright are not used to limit the access or legal rights of the compilation's users beyond what the individual works permit. Inclusion of a covered work in an aggregate does not cause this License to apply to the other parts of the aggregate.
-6. Conveying Non-Source Forms.
+6.Conveying Non-Source Forms.
 You may convey a covered work in object code form under the terms of sections 4 and 5, provided that you also convey the machine-readable Corresponding Source under the terms of this License, in one of these ways:
     a) Convey the object code in, or embodied in, a physical product (including a physical distribution medium), accompanied by the Corresponding Source fixed on a durable physical medium customarily used for software interchange.
@@ -187,7 +188,7 @@ The requirement to provide Installation Information does not include a requireme
 Corresponding Source conveyed, and Installation Information provided, in accord with this section must be in a format that is publicly documented (and with an implementation available to the public in source code form), and must require no special password or key for unpacking, reading or copying.
-7. Additional Terms.
+7.Additional Terms.
 “Additional permissions” are terms that supplement the terms of this License by making exceptions from one or more of its conditions. Additional permissions that are applicable to the entire Program shall be treated as though they were included in this License, to the extent that they are valid under applicable law. If additional permissions apply only to part of the Program, that part may be used separately under those permissions, but the entire Program remains governed by this License without regard to the additional permissions.
 When you convey a copy of a covered work, you may at your option remove any additional permissions from that copy, or from any part of it. (Additional permissions may be written to require their own removal in certain cases when you modify the work.) You may place additional permissions on material, added by you to a covered work, for which you have or can give appropriate copyright permission.
@@ -212,7 +213,7 @@ If you add terms to a covered work in accord with this section, you must place,
 Additional terms, permissive or non-permissive, may be stated in the form of a separately written license, or stated as exceptions; the above requirements apply either way.
-8. Termination.
+8.Termination.
 You may not propagate or modify a covered work except as expressly provided under this License. Any attempt otherwise to propagate or modify it is void, and will automatically terminate your rights under this License (including any patent licenses granted under the third paragraph of section 11).
 However, if you cease all violation of this License, then your license from a particular copyright holder is reinstated (a) provisionally, unless and until the copyright holder explicitly and finally terminates your license, and (b) permanently, if the copyright holder fails to notify you of the violation by some reasonable means prior to 60 days after the cessation.
@@ -221,17 +222,17 @@ Moreover, your license from a particular copyright holder is reinstated permanen
 Termination of your rights under this section does not terminate the licenses of parties who have received copies or rights from you under this License. If your rights have been terminated and not permanently reinstated, you do not qualify to receive new licenses for the same material under section 10.
-9. Acceptance Not Required for Having Copies.
+9.Acceptance Not Required for Having Copies.
 You are not required to accept this License in order to receive or run a copy of the Program. Ancillary propagation of a covered work occurring solely as a consequence of using peer-to-peer transmission to receive a copy likewise does not require acceptance. However, nothing other than this License grants you permission to propagate or modify any covered work. These actions infringe copyright if you do not accept this License. Therefore, by modifying or propagating a covered work, you indicate your acceptance of this License to do so.
-10. Automatic Licensing of Downstream Recipients.
+10.Automatic Licensing of Downstream Recipients.
 Each time you convey a covered work, the recipient automatically receives a license from the original licensors, to run, modify and propagate that work, subject to this License. You are not responsible for enforcing compliance by third parties with this License.
 An “entity transaction” is a transaction transferring control of an organization, or substantially all assets of one, or subdividing an organization, or merging organizations. If propagation of a covered work results from an entity transaction, each party to that transaction who receives a copy of the work also receives whatever licenses to the work the party's predecessor in interest had or could give under the previous paragraph, plus a right to possession of the Corresponding Source of the work from the predecessor in interest, if the predecessor has it or can get it with reasonable efforts.
 You may not impose any further restrictions on the exercise of the rights granted or affirmed under this License. For example, you may not impose a license fee, royalty, or other charge for exercise of rights granted under this License, and you may not initiate litigation (including a cross-claim or counterclaim in a lawsuit) alleging that any patent claim is infringed by making, using, selling, offering for sale, or importing the Program or any portion of it.
-11. Patents.
+11.Patents.
 A “contributor” is a copyright holder who authorizes use under this License of the Program or a work on which the Program is based. The work thus licensed is called the contributor's “contributor version”.
 A contributor's “essential patent claims” are all patent claims owned or controlled by the contributor, whether already acquired or hereafter acquired, that would be infringed by some manner, permitted by this License, of making, using, or selling its contributor version, but do not include claims that would be infringed only as a consequence of further modification of the contributor version. For purposes of this definition, “control” includes the right to grant patent sublicenses in a manner consistent with the requirements of this License.
@@ -248,13 +249,13 @@ A patent license is “discriminatory” if it does not include within the scope
 Nothing in this License shall be construed as excluding or limiting any implied license or other defenses to infringement that may otherwise be available to you under applicable patent law.
-12. No Surrender of Others' Freedom.
+12.No Surrender of Others' Freedom.
 If conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot convey a covered work so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not convey it at all. For example, if you agree to terms that obligate you to collect a royalty for further conveying from those to whom you convey the Program, the only way you could satisfy both those terms and this License would be to refrain entirely from conveying the Program.
-13. Use with the GNU Affero General Public License.
+13.Use with the GNU Affero General Public License.
 Notwithstanding any other provision of this License, you have permission to link or combine any covered work with a work licensed under version 3 of the GNU Affero General Public License into a single combined work, and to convey the resulting work. The terms of this License will continue to apply to the part which is the covered work, but the special requirements of the GNU Affero General Public License, section 13, concerning interaction through a network will apply to the combination as such.
-14. Revised Versions of this License.
+14.Revised Versions of this License.
 The Free Software Foundation may publish revised and/or new versions of the GNU General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns.
 Each version is given a distinguishing version number. If the Program specifies that a certain numbered version of the GNU General Public License “or any later version” applies to it, you have the option of following the terms and conditions either of that numbered version or of any later version published by the Free Software Foundation. If the Program does not specify a version number of the GNU General Public License, you may choose any version ever published by the Free Software Foundation.
@@ -263,13 +264,13 @@ If the Program specifies that a proxy can decide which future versions of the GN
 Later license versions may give you additional or different permissions. However, no additional obligations are imposed on any author or copyright holder as a result of your choosing to follow a later version.
-15. Disclaimer of Warranty.
+15.Disclaimer of Warranty.
 THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.
-16. Limitation of Liability.
+16.Limitation of Liability.
 IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MODIFIES AND/OR CONVEYS THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
-17. Interpretation of Sections 15 and 16.
+17.Interpretation of Sections 15 and 16.
 If the disclaimer of warranty and limitation of liability provided above cannot be given local legal effect according to their terms, reviewing courts shall apply local law that most closely approximates an absolute waiver of all civil liability in connection with the Program, unless a warranty or assumption of liability accompanies a copy of the Program in return for a fee.
 END OF TERMS AND CONDITIONS
@@ -297,7 +298,7 @@ If the program does terminal interaction, make it output a short notice like thi
     This program comes with ABSOLUTELY NO WARRANTY; for details type `show w'.
     This is free software, and you are welcome to redistribute it under certain conditions; type `show c' for details.
-The hypothetical commands `show w' and `show c' should show the appropriate parts of the General Public License. Of course, your program's commands might be different; for a GUI interface, you would use an “about box”.
+The hypothetical commands `show w' and`show c' should show the appropriate parts of the General Public License. Of course, your program's commands might be different; for a GUI interface, you would use an “about box”.
 You should also get your employer (if you work as a programmer) or school, if any, to sign a “copyright disclaimer” for the program, if necessary. For more information on this, and how to apply and follow the GNU GPL, see <http://www.gnu.org/licenses/>.
@@ -0,0 +1,142 @@
 # ADR-0001: Repository Structure
 * **Status:** Accepted
 * **Date:** 2026-07-12
 * **Decision Makers:** LUNA Charts Maintainers
 ---
 ## Context
 LUNA Charts is designed as an open-source charting library with a strong focus on accessibility, maintainability, and long-term evolution.
 The project consists of multiple concerns, including source code, documentation, examples, testing infrastructure, and continuous integration.
 A repository structure was required that supports collaborative development while keeping the project easy to understand for contributors and maintainers.
 The repository should also support future growth without requiring structural changes.
 ---
 ## Decision Drivers
 The following factors influenced this decision:
 * Maintainability
 * Developer Experience
 * Open Source Collaboration
 * Modular Architecture
 * Shared Tooling
 * Consistent Build Process
 * Long-Term Evolution
 ---
 ## Considered Alternatives
 | Alternative                          | Description                                                                        |
 | ------------------------------------ | ---------------------------------------------------------------------------------- |
 | Multiple repositories                | Separate repositories for documentation, examples, and library packages.           |
 | Single repository without workspaces | One repository containing all files without workspace separation.                  |
 | **Monorepo using pnpm Workspaces**   | One repository containing all project artifacts with logical workspace separation. |
 Multiple repositories were rejected because they increase maintenance effort, duplicate tooling, and complicate contribution workflows.
 A single repository without workspaces was rejected because the project is expected to grow over time and benefits from a clear modular organization.
 ---
 ## Decision
 LUNA Charts is implemented as a **pnpm-based monorepo**.
 The repository contains all project artifacts, including:
 * Source code
 * Documentation
 * Storybook
 * Examples
 * Architecture documentation
 * Architecture Decision Records (ADRs)
 * CI/CD configuration
 The repository is organized into logical workspaces.
 ```text
 luna-charts/
 │
 ├── packages/
 │   └── luna-charts/
 │
 ├── apps/
 │   ├── storybook/
 │   └── docs/
 │
 ├── docs/
 │   ├── architecture/
 │   └── adr/
 │
 ├── examples/
 │
 └── .github/
 ```
 Internally, the library is organized into architectural modules such as:
 * Core
 * Charts
 * Themes
 * Utilities
 These modules are implementation details and are **not** exposed as individual npm packages.
 ---
 ## Rationale
 A monorepo provides a single source of truth for the entire project.
 All contributors work within the same repository using a shared toolchain, coding standards, testing infrastructure, and documentation.
 Using **pnpm Workspaces** enables clear separation of responsibilities while avoiding duplicated dependencies and configuration.
 This structure supports the project's architecture-first approach and simplifies future expansion.
 ---
 ## Consequences
 ### Positive
 * Single source of truth
 * Simplified onboarding for contributors
 * Shared tooling and configuration
 * Consistent CI/CD pipeline
 * Easier dependency management
 * Centralized documentation
 * Scalable project organization
 ### Negative
 * Larger repository size
 * Contributors clone the complete repository
 * Workspace configuration introduces a small amount of additional complexity
 ---
 ## Related TOGAF Phases
 * Architecture Vision (Phase A)
 * Technology Architecture (Phase D)
 * Opportunities & Solutions (Phase E)
 * Migration Planning (Phase F)
 * Implementation Governance (Phase G)
 * Architecture Change Management (Phase H)
 ---
 ## References
 * LUNA Charts Architecture Wiki
 * ADR-0002: Technology Stack
 * pnpm Workspaces Documentation
@@ -0,0 +1,211 @@
 # ADR-0002: Technology Stack
 * **Status:** Accepted
 * **Date:** 2026-07-12
 * **Decision Makers:** LUNA Charts Maintainers
 ---
 ## Context
 LUNA Charts is an open-source charting library designed to provide accessible, framework-agnostic, and strongly typed chart components.
 The selected technology stack must support the architectural principles defined during the TOGAF Architecture Development Method (ADM), including:
 * Accessibility by Design
 * Framework Agnosticism
 * Strong Type Safety
 * Component-Based Architecture
 * High Developer Experience
 * Open Source Collaboration
 * Long-Term Maintainability
 Rather than selecting technologies based on popularity, each technology is evaluated according to its ability to support these architectural goals.
 ---
 ## Decision Drivers
 The following factors influenced the decision:
 * Accessibility
 * Framework Agnosticism
 * Type Safety
 * Developer Experience
 * Maintainability
 * Testability
 * Documentation
 * Open Source Collaboration
 * Long-Term Evolution
 ---
 ## Considered Alternatives
 | Technology Area         | Considered Alternatives                         | Selected           |
 | ----------------------- | ----------------------------------------------- | ------------------ |
 | Component Framework     | React, Vue, Angular, Lit, StencilJS             | **StencilJS**      |
 | Component Documentation | Storybook, Styleguidist                         | **Storybook**      |
 | Project Documentation   | Docusaurus, VitePress, Starlight                | **Starlight**      |
 | Package Manager         | npm, Yarn, pnpm                                 | **pnpm**           |
 | Unit Testing            | Vitest, Jest                                    | **Jest**           |
 | Browser Testing         | Cypress, Playwright                             | **Playwright**     |
 | Accessibility Testing   | Manual Testing Only, axe-core                   | **axe-core**       |
 | Code Formatting         | Manual Formatting, Prettier                     | **Prettier**       |
 | Static Analysis         | TSLint, ESLint                                  | **ESLint**         |
 | Versioning              | Manual Versioning, Semantic Release, Changesets | **Changesets**     |
 | Continuous Integration  | GitLab CI, Azure Pipelines, GitHub Actions      | **GitHub Actions** |
 The selected technologies best support the project's architectural goals while remaining broadly adopted and well documented.
 ---
 ## Decision
 The following technology stack is adopted for the implementation of LUNA Charts.
 | Technology         | Purpose                                             |
 | ------------------ | --------------------------------------------------- |
 | **StencilJS**      | Web Component development                           |
 | **Storybook**      | Interactive component documentation and development |
 | **Starlight**      | Project and architecture documentation              |
 | **TypeScript**     | Strong typing and developer tooling                 |
 | **pnpm**           | Package management and workspace support            |
 | **Jest**           | Unit testing                                        |
 | **Playwright**     | Browser and interaction testing                     |
 | **axe-core**       | Accessibility validation                            |
 | **ESLint**         | Static code analysis                                |
 | **Prettier**       | Consistent code formatting                          |
 | **Changesets**     | Versioning and release management                   |
 | **GitHub Actions** | Continuous Integration                              |
 The technology stack is considered part of the project's architecture and may only be changed through a new Architecture Decision Record.
 ---
 ## Rationale
 Each technology has been selected because it directly supports one or more architectural principles.
 ### StencilJS
 StencilJS enables the development of standards-based Web Components.
 This aligns with the project's goal of remaining framework agnostic while allowing framework-specific wrappers to be generated automatically during the build process.
 ---
 ### Storybook
 Storybook provides an isolated environment for component development.
 It supports rapid development, interactive examples, accessibility validation, and visual review of chart components.
 ---
 ### Starlight
 Starlight serves as the central documentation platform.
 It separates architectural documentation from component documentation and supports long-term maintainability of the project's knowledge base.
 ---
 ### TypeScript
 TypeScript enables strong compile-time validation.
 It improves the developer experience by detecting integration errors early and providing comprehensive IDE support.
 ---
 ### pnpm
 pnpm Workspaces enable a modular repository structure while maintaining a single source of truth for dependencies and tooling.
 ---
 ### Jest
 Jest provides fast unit testing for business logic, utility functions, configuration handling, validation, and other non-browser-specific functionality.
 ---
 ### Playwright
 Playwright validates component behavior inside real browsers.
 It is used to verify keyboard interaction, focus management, SVG rendering, and other browser-dependent accessibility features.
 ---
 ### axe-core
 axe-core automatically validates accessibility requirements and complements manual accessibility reviews.
 ---
 ### ESLint and Prettier
 Both tools ensure consistent coding standards across the project and reduce friction during code reviews.
 ---
 ### Changesets
 Changesets manages package versioning and release notes while keeping release decisions under maintainer control.
 ---
 ### GitHub Actions
 GitHub Actions automates testing, validation, and release workflows to ensure consistent software quality.
 ---
 ## Consequences
 ### Positive
 * Technology stack directly supports architectural principles.
 * Strong accessibility support throughout development.
 * Framework-independent component model.
 * Excellent developer experience.
 * Consistent documentation workflow.
 * High maintainability.
 * Modern testing strategy.
 * Simplified contributor onboarding.
 * Automated quality assurance.
 * Scalable project foundation.
 ### Negative
 * Initial project setup is more complex.
 * Contributors must become familiar with multiple development tools.
 * Toolchain maintenance requires periodic updates.
 * CI configuration is more comprehensive than for smaller projects.
 ---
 ## Related TOGAF Phases
 * Architecture Vision (Phase A)
 * Information Systems Architecture (Phase C)
 * Technology Architecture (Phase D)
 * Opportunities & Solutions (Phase E)
 * Migration Planning (Phase F)
 * Implementation Governance (Phase G)
 ---
 ## References
 * LUNA Charts Architecture Wiki
 * ADR-0001: Repository Structure
 * ADR-0003: Web Components as Public API
 * StencilJS Documentation
 * Storybook Documentation
 * Starlight Documentation
 * Playwright Documentation
 * Jest Documentation
 * pnpm Documentation
@@ -0,0 +1,110 @@
 # ADR-0003: Web Components as Public API
 * **Status:** Accepted
 * **Date:** 2026-07-12
 * **Decision Makers:** LUNA Charts Maintainers
 ---
 ## Context
 LUNA Charts is intended to be an open-source charting library that can be integrated into applications regardless of the frontend framework used.
 A primary architectural objective defined during the Architecture Vision and Technology Architecture phases is **framework agnosticism**. Consumers should be able to use LUNA Charts in React, Angular, Vue, Svelte, or plain HTML applications without requiring framework-specific implementations of the chart components.
 The public API therefore had to be based on a stable and widely adopted web standard rather than a framework-specific component model.
 ---
 ## Decision Drivers
 The following factors influenced this decision:
 * Framework Agnosticism
 * Standards Compliance
 * Long-Term Maintainability
 * Accessibility
 * Developer Experience
 * Component Reusability
 * Open Web Platform
 * Future Compatibility
 ---
 ## Considered Alternatives
 | Alternative                            | Description                                                       |
 | -------------------------------------- | ----------------------------------------------------------------- |
 | React Components                       | Components implemented exclusively for React.                     |
 | Vue Components                         | Components implemented exclusively for Vue.                       |
 | Angular Components                     | Components implemented exclusively for Angular.                   |
 | Separate implementations per framework | Independent implementations for each supported framework.         |
 | **Web Components**                     | Standards-based custom elements implemented using Web Components. |
 Framework-specific implementations were rejected because they increase maintenance effort, duplicate functionality, and couple the architecture to individual frontend ecosystems.
 Maintaining multiple implementations would also increase the likelihood of inconsistent behavior across frameworks.
 ---
 ## Decision
 LUNA Charts exposes its public API exclusively through **Web Components**.
 The project uses **StencilJS** to implement these components according to the Web Components standard.
 Framework integrations (e.g., React, Angular, Vue) are generated automatically during the build process and are considered **integration adapters**, not independent implementations.
 The architecture therefore consists of a single component model with multiple consumption options.
 ---
 ## Rationale
 Web Components are an open web standard supported by all modern browsers.
 By building directly upon this standard, LUNA Charts remains independent of any frontend framework while still supporting popular ecosystems through automatically generated wrappers.
 This approach minimizes duplicated implementation effort and guarantees consistent functionality across all supported platforms.
 Using a single implementation also simplifies testing, documentation, maintenance, and accessibility validation.
 Framework wrappers remain lightweight integration layers and do not introduce architectural differences.
 ---
 ## Consequences
 ### Positive
 * Framework-independent public API.
 * Single implementation for all supported platforms.
 * Reduced maintenance effort.
 * Consistent behavior across frameworks.
 * Simplified testing and documentation.
 * Better long-term stability.
 * Supports future frontend frameworks without redesigning the library.
 ### Negative
 * Developers unfamiliar with Web Components may require additional documentation.
 * Framework wrappers depend on the capabilities provided by StencilJS.
 * Some framework-specific features cannot be exposed without breaking framework independence.
 ---
 ## Related TOGAF Phases
 * Architecture Vision (Phase A)
 * Information Systems Architecture (Phase C)
 * Technology Architecture (Phase D)
 * Opportunities & Solutions (Phase E)
 ---
 ## References
 * LUNA Charts Architecture Wiki
 * ADR-0002: Technology Stack
 * StencilJS Documentation
 * Web Components Specification
@@ -0,0 +1,129 @@
 # ADR-0004: SVG as Rendering Technology
 * **Status:** Accepted
 * **Date:** 2026-07-12
 * **Decision Makers:** LUNA Charts Maintainers
 ---
 ## Context
 One of the primary goals of LUNA Charts is to provide accessible chart components that support modern accessibility standards and assist developers in creating WCAG-compliant data visualizations.
 Charts are graphical user interfaces that contain meaningful information. Depending on the chart type, individual graphical elements such as bars, points, labels, legends, and axes may need to be discoverable by assistive technologies, focusable using the keyboard, or interactable by users.
 The rendering technology therefore has a direct impact on accessibility, developer experience, testing capabilities, maintainability, and future extensibility.
 A rendering technology had to be selected that supports these architectural goals while remaining compatible with modern browsers and Web Components.
 ---
 ## Decision Drivers
 The following factors influenced this decision:
 * Accessibility
 * WCAG Compliance
 * Semantic Structure
 * Keyboard Navigation
 * Focus Management
 * Screen Reader Support
 * Developer Experience
 * Maintainability
 * Browser Compatibility
 * Long-Term Evolution
 ---
 ## Considered Alternatives
 | Alternative      | Description                                               |
 | ---------------- | --------------------------------------------------------- |
 | HTML Elements    | Represent charts using standard HTML elements.            |
 | Canvas           | Render graphics using the HTML Canvas API.                |
 | Hybrid Rendering | Combine Canvas and SVG depending on the chart type.       |
 | **SVG**          | Render all chart graphics using Scalable Vector Graphics. |
 HTML was rejected because it is not designed to represent complex graphical visualizations.
 Canvas was rejected because graphical objects are rendered as pixels rather than DOM elements. This makes individual chart elements difficult to expose to assistive technologies and increases implementation complexity for keyboard interaction and accessibility.
 Hybrid rendering was rejected because it would introduce two rendering models, increasing architectural complexity, testing effort, and maintenance costs.
 ---
 ## Decision
 All chart visualizations within LUNA Charts are rendered using **Scalable Vector Graphics (SVG)**.
 Each visual element (e.g., bars, lines, points, labels, legends, and axes) is represented as an individual SVG element within the DOM.
 Accessibility information, keyboard navigation, focus management, and interaction are implemented directly on these SVG elements.
 Canvas is not used as a rendering technology for chart components.
 ---
 ## Rationale
 SVG integrates directly into the browser's Document Object Model (DOM), allowing every graphical element to be individually identified, styled, focused, and enriched with accessibility information.
 This capability aligns with the project's goal of supporting accessible chart implementations by design.
 Using SVG enables the library to:
 * associate semantic information with graphical elements,
 * support keyboard navigation,
 * expose meaningful structures to assistive technologies,
 * apply standard web accessibility techniques,
 * simplify automated accessibility testing,
 * integrate naturally with Web Components.
 SVG also provides excellent scalability across different display resolutions without requiring additional rendering logic.
 Although Canvas may provide better rendering performance for extremely large datasets, accessibility and maintainability are considered higher architectural priorities for LUNA Charts.
 ---
 ## Consequences
 ### Positive
 * Native DOM representation of graphical elements.
 * Improved accessibility support.
 * Better compatibility with assistive technologies.
 * Simplified keyboard navigation.
 * Simplified focus management.
 * Easier automated accessibility testing.
 * Resolution-independent rendering.
 * Consistent styling using CSS.
 * Better integration with Web Components.
 * Simplified debugging using browser developer tools.
 ### Negative
 * Rendering performance may decrease for extremely large datasets.
 * SVG documents become larger as chart complexity increases.
 * Very large visualizations may require optimization techniques such as virtualization or data aggregation.
 These trade-offs are considered acceptable because accessibility and maintainability have higher architectural priority than maximum rendering performance.
 ---
 ## Related TOGAF Phases
 * Architecture Vision (Phase A)
 * Business Architecture (Phase B)
 * Information Systems Architecture (Phase C)
 * Technology Architecture (Phase D)
 * Opportunities & Solutions (Phase E)
 ---
 ## References
 * LUNA Charts Architecture Wiki
 * ADR-0002: Technology Stack
 * ADR-0003: Web Components as Public API
 * Scalable Vector Graphics (SVG) Specification
 * Web Content Accessibility Guidelines (WCAG)
@@ -0,0 +1,139 @@
 # ADR-000500: Accessibility as a Cross-Cutting Concern
 * **Status:** Accepted
 * **Date:** 2026-07-12
 * **Decision Makers:** LUNA Charts Maintainers
 ---
 ## Context
 Accessibility is the primary quality attribute of LUNA Charts.
 The project's objective is not only to render charts but also to support developers in creating accessible data visualizations that align with the Web Content Accessibility Guidelines (WCAG).
 During the architectural design process, accessibility was initially considered as a separate subsystem responsible for validating and enforcing accessibility requirements.
 Further analysis revealed that accessibility affects nearly every architectural layer of the system.
 Rendering, component APIs, configuration, validation, interaction, keyboard navigation, documentation, and testing all contribute to the accessibility of the final chart.
 As a result, accessibility cannot be implemented as an isolated engine without introducing architectural inconsistencies.
 ---
 ## Decision Drivers
 The following factors influenced this decision:
 * Accessibility by Design
 * WCAG Compliance
 * Separation of Concerns
 * Maintainability
 * Consistency
 * Developer Experience
 * Long-Term Evolution
 * Testability
 ---
 ## Considered Alternatives
 | Alternative                    | Description                                                                                                |
 | ------------------------------ | ---------------------------------------------------------------------------------------------------------- |
 | Dedicated Accessibility Engine | A centralized subsystem responsible for accessibility validation and enforcement.                          |
 | Accessibility Utilities        | A collection of reusable accessibility helper functions.                                                   |
 | **Cross-Cutting Concern**      | Accessibility is integrated into every architectural layer where accessibility-related decisions are made. |
 A dedicated accessibility engine was rejected because accessibility cannot be guaranteed after a chart has already been designed or rendered.
 Accessibility decisions must be made continuously throughout the rendering process and component lifecycle.
 Accessibility utilities remain part of the implementation but do not represent the architectural model.
 ---
 ## Decision
 Accessibility is treated as a **cross-cutting concern** throughout the entire architecture of LUNA Charts.
 Accessibility responsibilities are distributed across multiple architectural modules rather than centralized in a single subsystem.
 Examples include:
 * Public component APIs
 * TypeScript type definitions
 * Validation
 * Rendering
 * SVG generation
 * Keyboard interaction
 * Focus management
 * Documentation
 * Automated testing
 Each architectural component is responsible for implementing the accessibility requirements relevant to its own responsibility.
 ---
 ## Rationale
 Accessibility is not a feature that can be added after rendering has completed.
 Instead, accessibility emerges from many architectural decisions working together.
 Examples include:
 * selecting SVG instead of Canvas,
 * designing semantic component APIs,
 * exposing accessible keyboard interaction,
 * generating meaningful DOM structures,
 * providing strongly typed configuration,
 * validating accessibility-related configuration,
 * documenting accessibility behavior,
 * verifying accessibility through automated testing.
 Treating accessibility as a cross-cutting concern ensures that accessibility remains an architectural responsibility rather than an isolated implementation detail.
 This approach also aligns with established software architecture principles, where quality attributes such as security, logging, and observability are commonly treated as cross-cutting concerns.
 ---
 ## Consequences
 ### Positive
 * Accessibility is considered throughout the entire development process.
 * Architectural responsibilities remain clearly separated.
 * Accessibility becomes part of every feature rather than an optional extension.
 * Better support for WCAG-compliant chart implementations.
 * Simplified long-term maintenance.
 * Consistent accessibility behavior across all chart types.
 * Accessibility can be validated at multiple architectural levels.
 ### Negative
 * Accessibility responsibilities are distributed across multiple modules.
 * Contributors must understand accessibility requirements beyond their immediate implementation.
 * Architectural reviews must continuously consider accessibility implications.
 These trade-offs are acceptable because accessibility represents the primary quality objective of LUNA Charts.
 ---
 ## Related TOGAF Phases
 * Architecture Vision (Phase A)
 * Business Architecture (Phase B)
 * Information Systems Architecture (Phase C)
 * Technology Architecture (Phase D)
 * Implementation Governance (Phase G)
 ---
 ## References
 * LUNA Charts Architecture Wiki
 * ADR-000300: Web Components as Public API
 * ADR-000400: SVG as Rendering Technology
 * Web Content Accessibility Guidelines (WCAG)
 * WAI-ARIA Authoring Practices Guide
@@ -0,0 +1,190 @@
 # Architecture Decision Records (ADRs)
 Architecture Wiki: [https://wiki.byting-pandas.ninja/en/Projects/LUNA-Charts/Introduction]
 ## Purpose
 This directory contains the **Architecture Decision Records (ADRs)** for the LUNA Charts project.
 An Architecture Decision Record documents a significant architectural decision, the context in which it was made, the chosen solution, and its consequences.
 The goal is to preserve the reasoning behind architectural decisions so that future contributors and maintainers understand **why** a decision was made—not only **what** was implemented.
 ADRs complement the Architecture Development Method (ADM) documentation and serve as the primary record of architectural decisions throughout the project's lifecycle.
 ---
 ## Architecture Documentation
 The complete software architecture of LUNA Charts is documented in the official Architecture Wiki.
 The wiki follows the **TOGAF Architecture Development Method (ADM)** and describes the project from the initial vision through implementation governance and long-term architecture evolution.
 ### Architecture Wiki
 * Architecture Vision (Phase A)
 * Business Architecture (Phase B)
 * Information Systems Architecture (Phase C)
 * Technology Architecture (Phase D)
 * Opportunities & Solutions (Phase E)
 * Migration Planning (Phase F)
 * Implementation Governance (Phase G)
 * Architecture Change Management (Phase H)
 The ADRs contained in this directory should always be read together with the Architecture Wiki.
 The wiki describes the architecture as a whole, whereas ADRs explain the reasoning behind individual architectural decisions.
 ---
 ## Relationship to the Architecture Documentation
 | Architecture Wiki                            | Architecture Decision Records                       |
 | -------------------------------------------- | --------------------------------------------------- |
 | Describes the complete software architecture | Documents individual architectural decisions        |
 | Defines the overall system structure         | Explains why a specific solution was selected       |
 | Organized according to TOGAF ADM phases      | Organized chronologically by architectural decision |
 | Updated when the architecture evolves        | Added whenever a significant decision is made       |
 ADRs do **not** replace the Architecture Wiki.
 Likewise, the Architecture Wiki should not duplicate ADRs.
 Instead, both artifacts complement each other.
 ---
 ## When to Create an ADR
 An ADR should be created whenever a decision has a significant impact on the architecture of the project.
 Typical examples include:
 * Selecting a new technology
 * Introducing or replacing an architectural pattern
 * Changing the public API
 * Introducing a new rendering strategy
 * Changing accessibility principles
 * Modifying the repository structure
 * Changing release or governance processes
 Small implementation details, bug fixes, refactorings, or coding style decisions do **not** require an ADR.
 ---
 ## ADR Lifecycle
 Every ADR has one of the following statuses:
 | Status     | Description                                             |
 | ---------- | ------------------------------------------------------- |
 | Proposed   | The decision is under discussion.                       |
 | Accepted   | The decision has been approved and adopted.             |
 | Deprecated | The decision is no longer recommended but still exists. |
 | Superseded | The decision has been replaced by another ADR.          |
 | Discarded  | The proposal was rejected.                              |
 Only **Accepted** ADRs represent the current architecture.
 ---
 ## ADR Structure
 Each ADR follows the same structure.
 ```text
 Title
 Status
 Context
 Decision Drivers
 Considered Alternatives
 Decision
 Rationale
 Consequences
    Positive
    Negative
 Related TOGAF Phases
 References
 ```
 This structure ensures that every ADR answers the following questions:
 * **What** decision was made?
 * **Why** was the decision necessary?
 * **When** was it made?
 * **Who** approved the decision?
 * **What** are the expected consequences?
 ---
 ## Naming Convention
 ADRs use sequential numbering.
 Examples:
 ```text
 0001-repository-structure.md
 0002-technology-stack.md
 0003-svg-rendering.md
 ```
 The number is never reused.
 If an ADR becomes obsolete, its status changes instead of deleting the document.
 ---
 ## Decision Process
 Architectural decisions follow the governance model defined in **Implementation Governance (Phase G)**.
 ```text
 Proposal
        ↓
 Architecture Discussion
        ↓
 Architecture Review
        ↓
 Maintainer Decision
        ↓
 ADR Update
        ↓
 Implementation
 ```
 Community members are encouraged to participate in discussions.
 Final architectural decisions are made by the project maintainers.
 ---
 ## Relationship to Source Code
 Source code is expected to reflect accepted ADRs.
 If an implementation no longer follows an accepted ADR, one of the following actions should occur:
 * Update the implementation to match the ADR.
 * Replace the ADR with a new architectural decision.
 * Deprecate or supersede the ADR.
 Architectural changes should always be documented before or together with the implementation.
 ---
 ## References
 * TOGAF Architecture Development Method (ADM)
 * LUNA Charts Architecture Wiki
 * LUNA Charts Implementation Governance (Phase G)
 * LUNA Charts Architecture Change Management (Phase H)
@@ -0,0 +1,117 @@
 # ADR-XXXX: Title
 * **Status:** Proposed
 * **Date:** YYYY-MM-DD
 * **Decision Makers:** LUNA Charts Maintainers
 ---
 ## Context
 Describe the background that led to this decision.
 Questions that should be answered:
 * What problem needs to be solved?
 * Which architectural constraints exist?
 * Which project goals influence the decision?
 * Which stakeholders are affected?
 ---
 ## Decision Drivers
 List the primary factors that influenced the decision.
 Typical examples:
 * Accessibility
 * Performance
 * Developer Experience
 * Maintainability
 * Framework Agnosticism
 * Type Safety
 * Simplicity
 * Scalability
 ---
 ## Considered Alternatives
 Document all relevant alternatives.
 | Alternative | Description |
 | ----------- | ----------- |
 | Option A    | Description |
 | Option B    | Description |
 | Option C    | Description |
 Briefly explain why the alternatives were not selected.
 ---
 ## Decision
 Describe the selected solution.
 This section should clearly answer:
 > What has been decided?
 ---
 ## Rationale
 Explain why the selected solution best satisfies the decision drivers.
 This section should justify the decision from an architectural perspective.
 ---
 ## Consequences
 ### Positive
 Describe the expected benefits.
 Examples:
 * Improved maintainability
 * Better accessibility
 * Easier onboarding
 * Reduced complexity
 ### Negative
 Describe possible drawbacks.
 Examples:
 * Increased implementation effort
 * Additional maintenance
 * Performance trade-offs
 ---
 ## Related TOGAF Phases
 List all architecture phases that influenced this decision.
 Examples:
 * Architecture Vision (Phase A)
 * Technology Architecture (Phase D)
 * Implementation Governance (Phase G)
 ---
 ## References
 Provide references to related documentation.
 Examples:
 * Architecture Wiki
 * Other ADRs
 * External standards
 * Specifications
@@ -0,0 +1,8 @@
 // For more info, see https://github.com/storybookjs/eslint-plugin-storybook#configuration-flat-config-format
 import storybook from "eslint-plugin-storybook";
 import js from '@eslint/js';
 export default [js.configs.recommended, {
  ignores: ['**/dist/**', '**/www/**', '**/node_modules/**', '**/.stencil/**'],
 }, ...storybook.configs["flat/recommended"]];
@@ -4,7 +4,12 @@
  "description": "",
  "main": "index.js",
  "scripts": {
-    "test": "echo \"Error: no test specified\" && exit 1"
+    "lint": "eslint .",
    "format": "prettier --write .",
    "test": "echo \"Error: no test specified\" && exit 1",
    "changeset": "changeset",
    "version": "changeset version",
    "release": "changeset publish"
  },
  "keywords": [],
  "author": "",
@@ -20,5 +25,10 @@
      "onFail": "download"
    }
  },
-  "type": "module"
+  "type": "module",
  "devDependencies": {
    "@changesets/cli": "^2.31.0",
    "eslint": "^10.6.0",
    "prettier": "^3.9.4"
  }
 }
@@ -0,0 +1,15 @@
 # http://editorconfig.org
 root = true
 [*]
 charset = utf-8
 indent_style = space
 indent_size = 2
 end_of_line = lf
 insert_final_newline = true
 trim_trailing_whitespace = true
 [*.md]
 insert_final_newline = false
 trim_trailing_whitespace = false
@@ -0,0 +1,26 @@
 dist/
 www/
 loader/
 *~
 *.sw[mnpcod]
 *.log
 *.lock
 *.tmp
 *.tmp.*
 log.txt
 *.sublime-project
 *.sublime-workspace
 .stencil/
 .idea/
 .vscode/
 .sass-cache/
 .versions/
 node_modules/
 $RECYCLE.BIN/
 .DS_Store
 Thumbs.db
 UserInterfaceState.xcuserstate
 .env
@@ -0,0 +1,13 @@
 {
  "arrowParens": "avoid",
  "bracketSpacing": true,
  "jsxBracketSameLine": false,
  "jsxSingleQuote": false,
  "quoteProps": "consistent",
  "printWidth": 180,
  "semi": true,
  "singleQuote": true,
  "tabWidth": 2,
  "trailingComma": "all",
  "useTabs": false
 }
@@ -0,0 +1,9 @@
 const config = {
  stories: ['../src/**/*.stories.@(js|jsx|ts|tsx)'],
  addons: ['@storybook/addon-links', '@storybook/addon-docs'],
  framework: {
    name: '@stencil/storybook-plugin',
  },
 };
 export default config;
@@ -0,0 +1,15 @@
 // .storybook/preview.tsx
 import { defineCustomElements } from '../loader/index.js';
 import { setCustomElementsManifest } from '@stencil/storybook-plugin';
 import customElements from '../custom-elements.json';
 /**
 * Registers all custom elements in the Storybook preview.
 */
 defineCustomElements();
 /**
 * Loads and registers component metadata for Storybook.
 * This enables automatic generation of props, methods, events, slots, shadow parts, and CSS variables tables.
 */
 setCustomElementsManifest(customElements);
@@ -0,0 +1,21 @@
 MIT License
 Copyright (c) 2024
 Permission is hereby granted, free of charge, to any person obtaining a copy
 of this software and associated documentation files (the "Software"), to deal
 in the Software without restriction, including without limitation the rights
 to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
 copies of the Software, and to permit persons to whom the Software is
 furnished to do so, subject to the following conditions:
 The above copyright notice and this permission notice shall be included in all
 copies or substantial portions of the Software.
 THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
 IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
 FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
 AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
 LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
 OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
 SOFTWARE.
@@ -0,0 +1,480 @@
 /**
 * This is an autogenerated file created by the Stencil compiler.
 * DO NOT MODIFY IT MANUALLY
 */
 interface ComponentCompilerPropertyComplexType {
  /**
   * The string of the original type annotation in the Stencil source code
   */
  original: string;
  /**
   * A 'resolved' type, where e.g. imported types have been resolved and inlined
   *
   * For instance, an annotation like `(foo: Foo) => string;` will be
   * converted to `(foo: { foo: string }) => string;`.
   */
  resolved: string;
  /**
   * A record of the types which were referenced in the assorted type
   * annotation in the original source file.
   */
  references: ComponentCompilerTypeReferences;
 }
 type ComponentCompilerTypeReferences = Record<string, ComponentCompilerTypeReference>;
 interface ComponentCompilerTypeReference {
  /**
   * A type may be defined:
   * - locally (in the same file as the component that uses it)
   * - globally
   * - by importing it into a file (and is defined elsewhere)
   */
  location: "local" | "global" | "import";
  /**
   * The path to the type reference, if applicable (global types should not need a path associated with them)
   */
  path?: string;
  /**
   * An ID for this type which is unique within a Stencil project.
   */
  id: string;
  /**
   * Whether this type was imported as a default import (e.g., `import MyEnum from './my-enum'`)
   * vs a named import (e.g., `import { MyType } from './my-type'`)
   */
  isDefault?: boolean;
  /**
   * The name used in the import statement (before any user-defined alias).
   * For `import { XAxisOption as moo }`, this would be "XAxisOption".
   * This is the name exported by the source module.
   */
  referenceLocation?: string;
 }
 interface ComponentCompilerReferencedType {
  /**
   * The path to the module where the type is declared.
   */
  path: string;
  /**
   * The string of the original type annotation in the Stencil source code
   */
  declaration: string;
  /**
   * An extracted docstring
   */
  docstring: string;
 }
 interface ComponentCompilerEventComplexType {
  original: string;
  resolved: string;
  references: ComponentCompilerTypeReferences;
 }
 interface ComponentCompilerMethodComplexType {
  signature: string;
  parameters: JsonDocMethodParameter[];
  references: ComponentCompilerTypeReferences;
  return: string;
 }
 /**
 * The Type Library holds information about the types which are used in a
 * Stencil project. During compilation, Stencil gathers information about the
 * types which form part of a component's public API, such as properties
 * decorated with `@Prop`, `@Event`, `@Watch`, etc. This type information is
 * then added to the Type Library, where it can be accessed later on for
 * generating documentation.
 *
 * This information is included in the file written by the `docs-json` output
 * target (see {@link JsonDocs.typeLibrary}).
 */
 export type JsonDocsTypeLibrary = Record<string, ComponentCompilerReferencedType>;
 /**
 * A container for JSDoc metadata for a project
 */
 export interface JsonDocs {
  /**
   * The metadata for the JSDocs for each component in a Stencil project
   */
  components: JsonDocsComponent[];
  /**
   * The timestamp at which the metadata was generated, in the format YYYY-MM-DDThh:mm:ss
   */
  timestamp: string;
  compiler: {
    /**
     * The name of the compiler that generated the metadata
     */
    name: string;
    /**
     * The version of the Stencil compiler that generated the metadata
     */
    version: string;
    /**
     * The version of TypeScript that was used to generate the metadata
     */
    typescriptVersion: string;
  };
  typeLibrary: JsonDocsTypeLibrary;
 }
 /**
 * Container for JSDoc metadata for a single Stencil component
 */
 export interface JsonDocsComponent {
  /**
   * The directory containing the Stencil component, minus the file name.
   *
   * @example /workspaces/stencil-project/src/components/my-component
   */
  dirPath?: string;
  /**
   * The name of the file containing the Stencil component, with no path
   *
   * @example my-component.tsx
   */
  fileName?: string;
  /**
   * The full path of the file containing the Stencil component
   *
   * @example /workspaces/stencil-project/src/components/my-component/my-component.tsx
   */
  filePath?: string;
  /**
   * The path to the component's `readme.md` file, including the filename
   *
   * @example /workspaces/stencil-project/src/components/my-component/readme.md
   */
  readmePath?: string;
  /**
   * The path to the component's `usage` directory
   *
   * @example /workspaces/stencil-project/src/components/my-component/usage/
   */
  usagesDir?: string;
  /**
   * The encapsulation strategy for a component
   */
  encapsulation: "shadow" | "scoped" | "none";
  /**
   * The tag name for the component, for use in HTML
   */
  tag: string;
  /**
   * The contents of a component's `readme.md` that are user generated.
   *
   * Auto-generated contents are not stored in this reference.
   */
  readme: string;
  /**
   * The description of a Stencil component, found in the JSDoc that sits above the component's declaration
   */
  docs: string;
  /**
   * JSDoc tags found in the JSDoc comment written atop a component's declaration
   */
  docsTags: JsonDocsTag[];
  /**
   * The text from the class-level JSDoc for a Stencil component, if present.
   */
  overview?: string;
  /**
   * A mapping of usage example file names to their contents for the component.
   */
  usage: JsonDocsUsage;
  /**
   * Array of metadata for a component's `@Prop`s
   */
  props: JsonDocsProp[];
  /**
   * Array of metadata for a component's `@Method`s
   */
  methods: JsonDocsMethod[];
  /**
   * Array of metadata for a component's `@Event`s
   */
  events: JsonDocsEvent[];
  /**
   * Array of metadata for a component's `@Listen` handlers
   */
  listeners: JsonDocsListener[];
  /**
   * Array of metadata for a component's CSS styling information
   */
  styles: JsonDocsStyle[];
  /**
   * Array of component Slot information, generated from `@slot` tags
   */
  slots: JsonDocsSlot[];
  /**
   * Array of component Parts information, generate from `@part` tags
   */
  parts: JsonDocsPart[];
  /**
   * Array of custom states defined via @AttachInternals({ states: {...} })
   */
  customStates: JsonDocsCustomState[];
  /**
   * Array of metadata describing where the current component is used
   */
  dependents: string[];
  /**
   * Array of metadata listing the components which are used in current component
   */
  dependencies: string[];
  /**
   * Describes a tree of components coupling
   */
  dependencyGraph: JsonDocsDependencyGraph;
  /**
   * A deprecation reason/description found following a `@deprecated` tag
   */
  deprecation?: string;
 }
 export interface JsonDocsDependencyGraph {
  [tagName: string]: string[];
 }
 /**
 * A descriptor for a single JSDoc tag found in a block comment
 */
 export interface JsonDocsTag {
  /**
   * The tag name (immediately following the '@')
   */
  name: string;
  /**
   * The description that immediately follows the tag name
   */
  text?: string;
 }
 export interface JsonDocsValue {
  value?: string;
  type: string;
 }
 /**
 * A mapping of file names to their contents.
 *
 * This type is meant to be used when reading one or more usage markdown files associated with a component. For the
 * given directory structure:
 * ```
 * src/components/my-component
 * ├── my-component.tsx
 * └── usage
 *     ├── bar.md
 *     └── foo.md
 * ```
 * an instance of this type would include the name of the markdown file, mapped to its contents:
 * ```ts
 * {
 *   'bar': STRING_CONTENTS_OF_BAR.MD
 *   'foo': STRING_CONTENTS_OF_FOO.MD
 * }
 * ```
 */
 export interface JsonDocsUsage {
  [key: string]: string;
 }
 /**
 * An intermediate representation of a `@Prop` decorated member's JSDoc
 */
 export interface JsonDocsProp {
  /**
   * the name of the prop
   */
  name: string;
  complexType?: ComponentCompilerPropertyComplexType;
  /**
   * the type of the prop, in terms of the TypeScript type system (as opposed to JavaScript's or HTML's)
   */
  type: string;
  /**
   * `true` if the prop was configured as "mutable" where it was declared, `false` otherwise
   */
  mutable: boolean;
  /**
   * The name of the attribute that is exposed to configure a compiled web component
   */
  attr?: string;
  /**
   * `true` if the prop was configured to "reflect" back to HTML where it (the prop) was declared, `false` otherwise
   */
  reflectToAttr: boolean;
  /**
   * the JSDoc description text associated with the prop
   */
  docs: string;
  /**
   * JSDoc tags associated with the prop
   */
  docsTags: JsonDocsTag[];
  /**
   * The default value of the prop
   */
  default?: string;
  /**
   * Deprecation text associated with the prop. This is the text that immediately follows a `@deprecated` tag
   */
  deprecation?: string;
  values: JsonDocsValue[];
  /**
   * `true` if a component is declared with a '?', `false` otherwise
   *
   * @example
   * ```tsx
   * @Prop() componentProps?: any;
   * ```
   */
  optional: boolean;
  /**
   * `true` if a component is declared with a '!', `false` otherwise
   *
   * @example
   * ```tsx
   * @Prop() componentProps!: any;
   * ```
   */
  required: boolean;
  /**
   * `true` if the prop has a `get()`. `false` otherwise
   */
  getter: boolean;
  /**
   * `true` if the prop has a `set()`. `false` otherwise
   */
  setter: boolean;
 }
 export interface JsonDocsMethod {
  name: string;
  docs: string;
  docsTags: JsonDocsTag[];
  deprecation?: string;
  signature: string;
  returns: JsonDocsMethodReturn;
  parameters: JsonDocMethodParameter[];
  complexType: ComponentCompilerMethodComplexType;
 }
 export interface JsonDocsMethodReturn {
  type: string;
  docs: string;
 }
 export interface JsonDocMethodParameter {
  name: string;
  type: string;
  docs: string;
 }
 export interface JsonDocsEvent {
  event: string;
  bubbles: boolean;
  cancelable: boolean;
  composed: boolean;
  complexType: ComponentCompilerEventComplexType;
  docs: string;
  docsTags: JsonDocsTag[];
  deprecation?: string;
  detail: string;
 }
 /**
 * Type describing a CSS Style, as described by a JSDoc-style comment
 */
 export interface JsonDocsStyle {
  /**
   * The name of the style
   */
  name: string;
  /**
   * The type/description associated with the style
   */
  docs: string;
  /**
   * The annotation used in the JSDoc of the style (e.g. `@prop`)
   */
  annotation: string;
  /**
   * The mode associated with the style
   */
  mode: string | undefined;
 }
 export interface JsonDocsListener {
  event: string;
  target?: string;
  capture: boolean;
  passive: boolean;
 }
 /**
 * A descriptor for a slot
 *
 * Objects of this type are translated from the JSDoc tag, `@slot`
 */
 export interface JsonDocsSlot {
  /**
   * The name of the slot. Defaults to an empty string for an unnamed slot.
   */
  name: string;
  /**
   * A textual description of the slot.
   */
  docs: string;
 }
 /**
 * A descriptor of a CSS Shadow Part
 *
 * Objects of this type are translated from the JSDoc tag, `@part`, or the 'part'
 * attribute on a component in TSX
 */
 export interface JsonDocsPart {
  /**
   * The name of the Shadow part
   */
  name: string;
  /**
   * A textual description of the Shadow part.
   */
  docs: string;
 }
 /**
 * A descriptor for a Custom State defined via @AttachInternals({ states: {...} })
 *
 * Custom states are exposed via the ElementInternals.states CustomStateSet
 * and can be targeted with the CSS `:state()` pseudo-class.
 *
 * @see https://developer.mozilla.org/en-US/docs/Web/API/CustomStateSet
 */
 export interface JsonDocsCustomState {
  /**
   * The name of the custom state (without dashes)
   */
  name: string;
  /**
   * The initial/default value of the state
   */
  initialValue: boolean;
  /**
   * A textual description of the custom state
   */
  docs: string;
 }
 /**
 * Represents a parsed block comment in a CSS, Sass, etc. file for a custom property.
 */
 export interface StyleDoc {
  /**
   * The name of the CSS property
   */
  name: string;
  /**
   * The user-defined description of the CSS property
   */
  docs: string;
  /**
   * The JSDoc-style annotation (e.g. `@prop`) that was used in the block comment to detect the comment.
   * Used to inform Stencil where the start of a new property's description starts (and where the previous description
   * ends).
   */
  annotation: "prop";
  /**
   * The Stencil style-mode that is associated with this property.
   */
  mode: string | undefined;
 }
 export {};
 declare const _default: JsonDocs;
 export default _default;
@@ -0,0 +1,101 @@
 {
  "timestamp": "2026-07-12T12:51:52",
  "compiler": {
    "name": "@stencil/core",
    "version": "4.43.5",
    "typescriptVersion": "5.8.3"
  },
  "components": [
    {
      "filePath": "src/components/my-component/my-component.tsx",
      "encapsulation": "shadow",
      "tag": "my-component",
      "readme": "# my-component\n\n\n",
      "docs": "",
      "docsTags": [],
      "usage": {},
      "props": [
        {
          "name": "first",
          "type": "string",
          "complexType": {
            "original": "string",
            "resolved": "string",
            "references": {}
          },
          "mutable": false,
          "attr": "first",
          "reflectToAttr": false,
          "docs": "The first name",
          "docsTags": [],
          "values": [
            {
              "type": "string"
            }
          ],
          "optional": true,
          "required": false,
          "getter": false,
          "setter": false
        },
        {
          "name": "last",
          "type": "string",
          "complexType": {
            "original": "string",
            "resolved": "string",
            "references": {}
          },
          "mutable": false,
          "attr": "last",
          "reflectToAttr": false,
          "docs": "The last name",
          "docsTags": [],
          "values": [
            {
              "type": "string"
            }
          ],
          "optional": true,
          "required": false,
          "getter": false,
          "setter": false
        },
        {
          "name": "middle",
          "type": "string",
          "complexType": {
            "original": "string",
            "resolved": "string",
            "references": {}
          },
          "mutable": false,
          "attr": "middle",
          "reflectToAttr": false,
          "docs": "The middle name",
          "docsTags": [],
          "values": [
            {
              "type": "string"
            }
          ],
          "optional": true,
          "required": false,
          "getter": false,
          "setter": false
        }
      ],
      "methods": [],
      "events": [],
      "listeners": [],
      "styles": [],
      "slots": [],
      "parts": [],
      "states": [],
      "dependents": [],
      "dependencies": [],
      "dependencyGraph": {}
    }
  ],
  "typeLibrary": {}
 }
@@ -0,0 +1,56 @@
 {
  "name": "luna-charts",
  "version": "0.0.1",
  "description": "Stencil Component Starter",
  "main": "dist/index.cjs.js",
  "module": "dist/index.js",
  "types": "dist/types/index.d.ts",
  "collection": "dist/collection/collection-manifest.json",
  "collection:main": "dist/collection/index.js",
  "unpkg": "dist/luna-charts/luna-charts.esm.js",
  "exports": {
    ".": {
      "import": "./dist/luna-charts/luna-charts.esm.js",
      "require": "./dist/luna-charts/luna-charts.cjs.js"
    },
    "./my-component": {
      "import": "./dist/components/my-component.js",
      "types": "./dist/components/my-component.d.ts"
    },
    "./loader": {
      "types": "./loader/index.d.ts",
      "import": "./loader/index.js",
      "require": "./loader/index.cjs"
    }
  },
  "repository": {
    "type": "git",
    "url": "https://github.com/stenciljs/component-starter.git"
  },
  "files": [
    "dist/",
    "loader/"
  ],
  "scripts": {
    "build": "stencil build",
    "start": "stencil build --dev --watch --serve",
    "test": "stencil-test --prod",
    "test:watch": "stencil-test --prod --watch",
    "generate": "stencil generate",
    "storybook": "storybook dev -p 6006 --no-open"
  },
  "devDependencies": {
    "@stencil/core": "^4.43.5",
    "@stencil/storybook-plugin": "^0.7.0",
    "@stencil/vitest": "^1.8.3",
    "@storybook/addon-links": "^10.5.0",
    "@types/node": "^22.13.5",
    "@vitest/browser-playwright": "^4.0.0",
    "playwright": "^1.52.0",
    "storybook": "^10.5.0",
    "vitest": "^4.0.0",
    "eslint-plugin-storybook": "10.5.0",
    "@storybook/addon-docs": "^10.5.0"
  },
  "license": "MIT"
 }
@@ -0,0 +1,111 @@
 [![Built With Stencil](https://img.shields.io/badge/-Built%20With%20Stencil-16161d.svg?logo=data%3Aimage%2Fsvg%2Bxml%3Bbase64%2CPD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0idXRmLTgiPz4KPCEtLSBHZW5lcmF0b3I6IEFkb2JlIElsbHVzdHJhdG9yIDE5LjIuMSwgU1ZHIEV4cG9ydCBQbHVnLUluIC4gU1ZHIFZlcnNpb246IDYuMDAgQnVpbGQgMCkgIC0tPgo8c3ZnIHZlcnNpb249IjEuMSIgaWQ9IkxheWVyXzEiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwL3N2ZyIgeG1sbnM6eGxpbms9Imh0dHA6Ly93d3cudzMub3JnLzE5OTkveGxpbmsiIHg9IjBweCIgeT0iMHB4IgoJIHZpZXdCb3g9IjAgMCA1MTIgNTEyIiBzdHlsZT0iZW5hYmxlLWJhY2tncm91bmQ6bmV3IDAgMCA1MTIgNTEyOyIgeG1sOnNwYWNlPSJwcmVzZXJ2ZSI%2BCjxzdHlsZSB0eXBlPSJ0ZXh0L2NzcyI%2BCgkuc3Qwe2ZpbGw6I0ZGRkZGRjt9Cjwvc3R5bGU%2BCjxwYXRoIGNsYXNzPSJzdDAiIGQ9Ik00MjQuNywzNzMuOWMwLDM3LjYtNTUuMSw2OC42LTkyLjcsNjguNkgxODAuNGMtMzcuOSwwLTkyLjctMzAuNy05Mi43LTY4LjZ2LTMuNmgzMzYuOVYzNzMuOXoiLz4KPHBhdGggY2xhc3M9InN0MCIgZD0iTTQyNC43LDI5Mi4xSDE4MC40Yy0zNy42LDAtOTIuNy0zMS05Mi43LTY4LjZ2LTMuNkgzMzJjMzcuNiwwLDkyLjcsMzEsOTIuNyw2OC42VjI5Mi4xeiIvPgo8cGF0aCBjbGFzcz0ic3QwIiBkPSJNNDI0LjcsMTQxLjdIODcuN3YtMy42YzAtMzcuNiw1NC44LTY4LjYsOTIuNy02OC42SDMzMmMzNy45LDAsOTIuNywzMC43LDkyLjcsNjguNlYxNDEuN3oiLz4KPC9zdmc%2BCg%3D%3D&colorA=16161d&style=flat-square)](https://stenciljs.com)
 # Stencil Component Starter
 > This is a starter project for building a standalone Web Components using Stencil.
 Stencil is a compiler for building fast web apps using Web Components.
 Stencil combines the best concepts of the most popular frontend frameworks into a compile-time rather than runtime tool. Stencil takes TypeScript, JSX, a tiny virtual DOM layer, efficient one-way data binding, an asynchronous rendering pipeline (similar to React Fiber), and lazy-loading out of the box, and generates 100% standards-based Web Components that run in any browser supporting the Custom Elements specification.
 Stencil components are just Web Components, so they work in any major framework or with no framework at all.
 ## Getting Started
 To start building a new web component using Stencil, clone this repo to a new directory:
 ```bash
 git clone https://github.com/stenciljs/component-starter.git my-component
 cd my-component
 git remote rm origin
 ```
 and run:
 ```bash
 npm install
 npm start
 ```
 To build the component for production, run:
 ```bash
 npm run build
 ```
 To run the unit tests for the components, run:
 ```bash
 npm test
 ```
 Need help? Check out our docs [here](https://stenciljs.com/docs/my-first-component).
 ## Naming Components
 When creating new component tags, we recommend _not_ using `stencil` in the component name (ex: `<stencil-datepicker>`). This is because the generated component has little to nothing to do with Stencil; it's just a web component!
 Instead, use a prefix that fits your company or any name for a group of related components. For example, all of the [Ionic-generated](https://ionicframework.com/) web components use the prefix `ion`.
 ## Using this component
 There are two strategies we recommend for using web components built with Stencil.
 The first step for all two of these strategies is to [publish to NPM](https://docs.npmjs.com/getting-started/publishing-npm-packages).
 You can read more about these different approaches in the [Stencil docs](https://stenciljs.com/docs/publishing).
 ### Lazy Loading
 If your Stencil project is built with the [`dist`](https://stenciljs.com/docs/distribution) output target, you can import a small bootstrap script that registers all components and allows you to load individual component scripts lazily.
 For example, given your Stencil project namespace is called `my-design-system`, to use `my-component` on any website, inject this into your HTML:
 ```html
 <script type="module" src="https://unpkg.com/my-design-system"></script>
 <!--
 To avoid unpkg.com redirects to the actual file, you can also directly import:
 https://unpkg.com/foobar-design-system@0.0.1/dist/foobar-design-system/foobar-design-system.esm.js
 -->
 <my-component first="Stencil" middle="'Don't call me a framework'" last="JS"></my-component>
 ```
 This will only load the necessary scripts needed to render `<my-component />`. Once more components of this package are used, they will automatically be loaded lazily.
 You can also import the script as part of your `node_modules` in your applications entry file:
 ```tsx
 import 'foobar-design-system/dist/foobar-design-system/foobar-design-system.esm.js';
 ```
 Check out this [Live Demo](https://stackblitz.com/edit/vitejs-vite-y6v26a?file=src%2Fmain.tsx).
 ### Standalone
 If you are using a Stencil component library with `dist-custom-elements`, we recommend importing Stencil components individually in those files where they are needed.
 To export Stencil components as standalone components make sure you have the [`dist-custom-elements`](https://stenciljs.com/docs/custom-elements) output target defined in your `stencil.config.ts`.
 For example, given you'd like to use `<my-component />` as part of a React component, you can import the component directly via:
 ```tsx
 import 'foobar-design-system/my-component';
 function App() {
  return (
    <>
      <div>
        <my-component
          first="Stencil"
          middle="'Don't call me a framework'"
          last="JS"
        ></my-component>
      </div>
    </>
  );
 }
 export default App;
 ```
 Check out this [Live Demo](https://stackblitz.com/edit/vitejs-vite-b6zuds?file=src%2FApp.tsx).
@@ -0,0 +1,68 @@
 /* eslint-disable */
 /* tslint:disable */
 /**
 * This is an autogenerated file created by the Stencil compiler.
 * It contains typing information for all components that exist in this project.
 */
 import { HTMLStencilElement, JSXBase } from "@stencil/core/internal";
 export namespace Components {
    interface MyComponent {
        /**
          * The first name
         */
        "first"?: string;
        /**
          * The last name
         */
        "last"?: string;
        /**
          * The middle name
         */
        "middle"?: string;
    }
 }
 declare global {
    interface HTMLMyComponentElement extends Components.MyComponent, HTMLStencilElement {
    }
    var HTMLMyComponentElement: {
        prototype: HTMLMyComponentElement;
        new (): HTMLMyComponentElement;
    };
    interface HTMLElementTagNameMap {
        "my-component": HTMLMyComponentElement;
    }
 }
 declare namespace LocalJSX {
    interface MyComponent {
        /**
          * The first name
         */
        "first"?: string;
        /**
          * The last name
         */
        "last"?: string;
        /**
          * The middle name
         */
        "middle"?: string;
    }
    interface MyComponentAttributes {
        "first": string;
        "middle": string;
        "last": string;
    }
    interface IntrinsicElements {
        "my-component": Omit<MyComponent, keyof MyComponentAttributes> & { [K in keyof MyComponent & keyof MyComponentAttributes]?: MyComponent[K] } & { [K in keyof MyComponent & keyof MyComponentAttributes as `attr:${K}`]?: MyComponentAttributes[K] } & { [K in keyof MyComponent & keyof MyComponentAttributes as `prop:${K}`]?: MyComponent[K] };
    }
 }
 export { LocalJSX as JSX };
 declare module "@stencil/core" {
    export namespace JSX {
        interface IntrinsicElements {
            "my-component": LocalJSX.IntrinsicElements["my-component"] & JSXBase.HTMLAttributes<HTMLMyComponentElement>;
        }
    }
 }
@@ -0,0 +1,31 @@
 import { render, h, describe, it, expect } from '@stencil/vitest';
 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('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>
    `);
  });
 });
@@ -0,0 +1,3 @@
 :host {
  display: block;
 }
@@ -0,0 +1,41 @@
 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',
  },
 };
@@ -0,0 +1,32 @@
 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>;
  }
 }
@@ -0,0 +1,19 @@
 # my-component
 <!-- Auto Generated Below -->
 ## Properties
 | Property | Attribute | Description     | Type     | Default     |
 | -------- | --------- | --------------- | -------- | ----------- |
 | `first`  | `first`   | The first name  | `string` | `undefined` |
 | `last`   | `last`    | The last name   | `string` | `undefined` |
 | `middle` | `middle`  | The middle name | `string` | `undefined` |
 ----------------------------------------------
 *Built with [StencilJS](https://stenciljs.com/)*
@@ -0,0 +1,14 @@
 <!DOCTYPE html>
 <html dir="ltr" lang="en">
  <head>
    <meta charset="utf-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0, minimum-scale=1.0, maximum-scale=5.0" />
    <title>Stencil Component Starter</title>
    <script type="module" src="/build/luna-charts.esm.js"></script>
    <script nomodule src="/build/luna-charts.js"></script>
  </head>
  <body>
    <my-component first="Stencil" middle="'Don't call me a framework'" last="JS"></my-component>
  </body>
 </html>
@@ -0,0 +1,12 @@
 /**
 * @fileoverview entry point for your component library
 *
 * This is the entry point for your component library. Use this file to export utilities,
 * constants or data structure that accompany your components.
 *
 * DO NOT use this file to export your components. Instead, use the recommended approaches
 * to consume components of this package as outlined in the `README.md`.
 */
 export { format } from './utils/utils';
 export type * from './components.d.ts';
@@ -0,0 +1,3 @@
 export function format(first?: string, middle?: string, last?: string): string {
  return (first || '') + (middle ? ` ${middle}` : '') + (last ? ` ${last}` : '');
 }
@@ -0,0 +1,20 @@
 import { describe, it, expect } from 'vitest';
 import { format } from './utils';
 describe('format', () => {
  it('returns empty string for no names defined', () => {
    expect(format(undefined, undefined, undefined)).toEqual('');
  });
  it('formats just first names', () => {
    expect(format('Joseph', undefined, undefined)).toEqual('Joseph');
  });
  it('formats first and last names', () => {
    expect(format('Joseph', undefined, 'Publique')).toEqual('Joseph Publique');
  });
  it('formats first, middle and last names', () => {
    expect(format('Joseph', 'Quincy', 'Publique')).toEqual('Joseph Quincy Publique');
  });
 });
@@ -0,0 +1,27 @@
 import { Config } from '@stencil/core';
 export const config: Config = {
  namespace: 'luna-charts',
  outputTargets: [
    {
      type: 'dist',
      esmLoaderPath: '../loader',
    },
    {
      type: 'dist-custom-elements',
      customElementsExportBehavior: 'auto-define-custom-elements',
      externalRuntime: false,
    },
    {
      type: 'docs-readme',
    },
    {
      type: 'www',
      serviceWorker: null, // disable service workers
    },
    {
      type: 'docs-json',
      file: './custom-elements.json',
    },
  ],
 };
@@ -0,0 +1,31 @@
 {
  "extends": "../../tsconfig.base.json",
  "compilerOptions": {
    "allowSyntheticDefaultImports": true,
    "allowUnreachableCode": false,
    "declaration": false,
    "experimentalDecorators": true,
    "lib": [
      "dom",
      "es2022"
    ],
    "moduleResolution": "bundler",
    "module": "esnext",
    "target": "es2022",
    "noUnusedLocals": true,
    "noUnusedParameters": true,
    "rootDir": "./",
    "jsx": "react",
    "jsxFactory": "h",
    "jsxFragmentFactory": "h.Fragment",
    "types": [
      "@stencil/vitest/globals"
    ]
  },
  "include": [
    "src"
  ],
  "exclude": [
    "node_modules"
  ]
 }
@@ -0,0 +1,3 @@
 import { defineCustomElements } from "./loader";
 defineCustomElements();
@@ -0,0 +1,32 @@
 import { defineVitestConfig } from '@stencil/vitest/config';
 import { playwright } from '@vitest/browser-playwright';
 export default defineVitestConfig({
  stencilConfig: './stencil.config.ts',
  test: {
    projects: [
      // Unit tests - stencil environment for component logic
      {
        test: {
          name: 'unit',
          include: ['src/**/*.unit.test.{ts,tsx}'],
          environment: 'stencil',
        },
      },
      // Component browser tests - real browser via Playwright
      {
        test: {
          name: 'browser',
          include: ['src/**/*.cmp.test.{ts,tsx}'],
          setupFiles: ['./vitest-setup.ts'],
          browser: {
            enabled: true,
            provider: playwright(),
            headless: true,
            instances: [{ browser: 'chromium' }],
          },
        },
      },
    ],
  },
 });
@@ -1,3 +1,5 @@
 packages:
  - "packages/*"
  - "apps/*"
 allowBuilds:
  esbuild: false
Author	SHA1	Message	Date
Ninosaurier	15b92fa27e	Added storybook with example in thw preview.tsx	2026-07-12 15:44:12 +02:00
Ninosaurier	54255b453a	tsconfig.json extends from tsconfig.base.json	2026-07-12 15:43:41 +02:00
Ninosaurier	193ce2b241	renamed tsconfig.base.yaml to tsconfig.base.json	2026-07-12 15:42:20 +02:00
Ninosaurier	a11bbcf6f7	Testing(stencil): First testing stencil workspace	2026-07-12 13:47:25 +02:00
Ninosaurier	ff9d18610c	build(stencil): initialize stencil workspace	2026-07-12 13:43:50 +02:00
Ninosaurier	8e38146cb0	Added the first 5 ADRs, which are important for first Work package "Groundwork"	2026-07-12 12:13:37 +02:00
Ninosaurier	dbf4b55072	Added Introduction as README.md for the ADRs and defined a template for possibly new ADRs	2026-07-12 12:13:02 +02:00
Ninosaurier	bd7cd1030a	Fixed all warnings	2026-07-12 01:15:50 +02:00
Ninosaurier	b722e113ab	Set configuration for changeset	2026-07-10 16:15:35 +02:00
Ninosaurier	8513c987c9	Installed ESLint and Prettier	2026-07-10 15:55:44 +02:00
		`@@ -0,0 +1,3 @@`
							`import { defineCustomElements } from "./loader";`

							`defineCustomElements();`