Merge pull request 'Prepared release v0.2.0 and merge dev into Main' (#34) from dev into main
Reviewed-on: #34
This commit is contained in:
@@ -1,5 +0,0 @@
|
||||
---
|
||||
'luna-charts': minor
|
||||
---
|
||||
|
||||
Establish the initial project foundation with architecture, documentation, governance, and development tooling.
|
||||
@@ -87,4 +87,4 @@ jobs:
|
||||
|
||||
- name: Run component tests (Playwright)
|
||||
working-directory: packages/luna-charts
|
||||
run: pnpm test:browser
|
||||
run: pnpm test:browser --passWithNoTests
|
||||
+1
-1
@@ -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"]
|
||||
|
||||
@@ -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
|
||||
@@ -59,8 +59,9 @@ luna-charts/
|
||||
|
||||
### Prerequisites
|
||||
|
||||
* Node.js `>= 22.0.0`
|
||||
* pnpm `11.11.0` (see `devEngines` in `package.json`; pnpm will be downloaded automatically via Corepack if missing)
|
||||
* [Node Version manager](https://github.com/nvm-sh/nvm/blob/master/README.md) `0.40.7`
|
||||
* Node.js `>= 24.0.0`. Use `nvm install 24` for it
|
||||
* pnpm `12.0.0`
|
||||
* Docker (required for running component/browser tests locally, see below)
|
||||
|
||||
### Installation
|
||||
|
||||
@@ -19,3 +19,6 @@ pnpm-debug.log*
|
||||
|
||||
# macOS-specific files
|
||||
.DS_Store
|
||||
|
||||
# IDE specific files
|
||||
.vscode
|
||||
|
||||
@@ -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
|
||||
+3
-3
@@ -1,7 +1,7 @@
|
||||
{
|
||||
"name": "docs",
|
||||
"type": "module",
|
||||
"version": "0.0.1",
|
||||
"version": "0.2.0",
|
||||
"scripts": {
|
||||
"dev": "astro dev",
|
||||
"start": "astro dev",
|
||||
@@ -10,8 +10,8 @@
|
||||
"astro": "astro"
|
||||
},
|
||||
"dependencies": {
|
||||
"@astrojs/starlight": "^0.41.3",
|
||||
"astro": "^7.0.2",
|
||||
"@astrojs/starlight": "^0.41.9",
|
||||
"astro": "^7.2.9",
|
||||
"sharp": "^0.34.5"
|
||||
}
|
||||
}
|
||||
Generated
-4323
File diff suppressed because it is too large
Load Diff
@@ -1,3 +0,0 @@
|
||||
allowBuilds:
|
||||
esbuild: true
|
||||
sharp: true
|
||||
@@ -1,11 +1,11 @@
|
||||
---
|
||||
title: "ADR-0001000: Repository Structure"
|
||||
title: "ADR-000100: Repository Structure"
|
||||
description: "Decision to use a pnpm-based monorepo structure for LUNA Charts."
|
||||
---
|
||||
|
||||
* **Status:** Accepted
|
||||
* **Date:** 2026-07-12
|
||||
* **Last Updated:** 2026-07-17
|
||||
* **Last Updated:** 2026-08-31
|
||||
* **Decision Makers:** LUNA Charts Maintainers
|
||||
|
||||
---
|
||||
|
||||
@@ -1,11 +1,11 @@
|
||||
---
|
||||
title: "ADR-0002000: Technology Stack"
|
||||
title: "ADR-000200: Technology Stack"
|
||||
description: "Selection of the technology stack for LUNA Charts based on the TOGAF architectural principles."
|
||||
---
|
||||
|
||||
* **Status:** Accepted
|
||||
* **Date:** 2026-07-12
|
||||
* **Last Updated:** 2006-07-17
|
||||
* **Last Updated:** 2026-07-17
|
||||
* **Decision Makers:** LUNA Charts Maintainers
|
||||
|
||||
---
|
||||
@@ -58,7 +58,7 @@ The following factors influenced the decision:
|
||||
| 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** |
|
||||
| Continuous Integration | GitLab CI, Azure Pipelines, Gitea Actions | **Gitea Actions** |
|
||||
|
||||
The selected technologies best support the project's architectural goals while remaining broadly adopted and well documented.
|
||||
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: "ADR-0003000: Web Components as Public API"
|
||||
title: "ADR-000300: Web Components as Public API"
|
||||
description: "Decision to make LUNA Charts' public API available exclusively via Web Components."
|
||||
---
|
||||
|
||||
|
||||
@@ -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/)
|
||||
@@ -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/)
|
||||
@@ -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/)
|
||||
@@ -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/)
|
||||
@@ -17,7 +17,7 @@ luna-charts/
|
||||
│
|
||||
├── examples/
|
||||
│
|
||||
├── .github/
|
||||
├── .gitea/
|
||||
│
|
||||
├── package.json
|
||||
└── pnpm-workspace.yaml
|
||||
|
||||
@@ -11,77 +11,92 @@ Instead of implementing features immediately, the project establishes a solid ar
|
||||
|
||||
---
|
||||
|
||||
## Current Status
|
||||
## Completed Milestones ✅
|
||||
|
||||
**Current Phase:** Groundwork
|
||||
|
||||
The project is currently preparing the technical and organizational foundation for future development.
|
||||
<details>
|
||||
<summary>**Completed:** Groundwork (v0.1.0)</summary>
|
||||
The project is preparing the technical and organizational foundation for future development.
|
||||
|
||||
Completed work includes:
|
||||
|
||||
- Repository structure
|
||||
- Development workflow
|
||||
- Architecture documentation (TOGAF ADM)
|
||||
- Architecture Decision Records (ADRs)
|
||||
- Project governance
|
||||
- Documentation infrastructure
|
||||
- **Repository structure:** Standardized layout for code, configurations, and assets.
|
||||
- \*\*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.
|
||||
- **Documentation infrastructure:** "Docs-as-Code" setup integrated into the repository.
|
||||
|
||||
At this stage, no production-ready chart components are available.
|
||||
|
||||
---
|
||||
|
||||
## Upcoming Milestones
|
||||
|
||||
### Foundation
|
||||
|
||||
- Create the initial StencilJS library
|
||||
- Establish Storybook for component development
|
||||
- Configure testing infrastructure
|
||||
- Configure CI/CD pipeline
|
||||
</details>
|
||||
|
||||
---
|
||||
|
||||
### First Proof of Concept
|
||||
<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.
|
||||
|
||||
Deliver the first functional chart implementation to validate the technical architecture.
|
||||
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.
|
||||
|
||||
- **Create the initial StencilJS library:** Initialize the codebase and core configurations for the web component engine.
|
||||
- **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.
|
||||
- **Configure CI/CD pipeline:** Automate linting, testing, and initial build checks on every repository push or pull request.
|
||||
</details>
|
||||
|
||||
---
|
||||
|
||||
## 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
|
||||
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
|
||||
- Accessibility validation
|
||||
- Framework integration
|
||||
- Community feedback
|
||||
- **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
|
||||
least one external framework (e.g. React or Vue).
|
||||
- **Community feedback:** Share the proof of concept for early feedback before scaling to further components.
|
||||
|
||||
---
|
||||
|
||||
### Minimum Viable Product (MVP)
|
||||
## Upcoming Milestones 🚀
|
||||
|
||||
Provide the first publicly usable version of LUNA Charts.
|
||||
### Minimum Viable Product (MVP) v1.0.0
|
||||
|
||||
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.
|
||||
|
||||
Expected outcomes include:
|
||||
|
||||
- Initial chart collection
|
||||
- Stable public API
|
||||
- Documentation
|
||||
- Example applications
|
||||
- Accessibility support
|
||||
- **Initial chart collection:** Ship a first stable set of chart types built on the validated architecture.
|
||||
- **Stable public API:** Freeze the public component API surface and document breaking-change policy.
|
||||
- **Documentation:** Complete user-facing documentation (usage guides, API reference, accessibility notes).
|
||||
- **Example applications:** Provide working examples for common framework integrations.
|
||||
- **Accessibility support:** Ensure all shipped components meet the project's WCAG target across the full component set.
|
||||
|
||||
---
|
||||
|
||||
### Community Growth
|
||||
|
||||
After the MVP, the project will gradually expand.
|
||||
|
||||
With a stable MVP in place, this milestone shifts focus toward expanding the library's reach,
|
||||
capabilities, and contributor base.
|
||||
Future work may include:
|
||||
|
||||
- Additional chart types
|
||||
- Advanced customization
|
||||
- Performance improvements
|
||||
- Extended framework support
|
||||
- Community contributions
|
||||
- Governance evolution
|
||||
- **Additional chart types:** Expand the component library beyond the initial MVP set.
|
||||
- **Advanced customization:** Add theming, styling, and configuration options requested by users.
|
||||
- **Performance improvements:** Optimize rendering and bundle size based on real-world usage.
|
||||
- **Extended framework support:** Broaden compatibility with additional frameworks and build tools.
|
||||
- **Community contributions:** Establish a smooth path for external contributors (good-first-issue labeling, contributor docs).
|
||||
- **Governance evolution:** Revisit and evolve project governance as the contributor base grows.
|
||||
|
||||
---
|
||||
|
||||
|
||||
+7
-6
@@ -1,6 +1,6 @@
|
||||
{
|
||||
"name": "LUNA-Charts",
|
||||
"version": "1.0.0",
|
||||
"version": "0.2.0",
|
||||
"description": "",
|
||||
"main": "index.js",
|
||||
"scripts": {
|
||||
@@ -20,16 +20,17 @@
|
||||
"author": "",
|
||||
"license": "ISC",
|
||||
"devEngines": {
|
||||
"runtime": {
|
||||
"name": "node",
|
||||
"version": ">=22.0.0"
|
||||
},
|
||||
"packageManager": {
|
||||
"name": "pnpm",
|
||||
"version": "11.11.0",
|
||||
"version": "12.0.0",
|
||||
"onFail": "download"
|
||||
},
|
||||
"runtime": {
|
||||
"name": "node",
|
||||
"version": ">=24.0.0"
|
||||
}
|
||||
},
|
||||
"packageManager": "pnpm@12.0.0",
|
||||
"type": "module",
|
||||
"devDependencies": {
|
||||
"@changesets/cli": "^2.31.0",
|
||||
|
||||
@@ -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.
|
||||
@@ -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",
|
||||
|
||||
@@ -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>
|
||||
`);
|
||||
});
|
||||
});
|
||||
@@ -1,3 +0,0 @@
|
||||
:host {
|
||||
display: block;
|
||||
}
|
||||
@@ -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',
|
||||
},
|
||||
};
|
||||
@@ -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>;
|
||||
}
|
||||
}
|
||||
@@ -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/)_
|
||||
Generated
+1317
-1059
File diff suppressed because it is too large
Load Diff
+7
-6
@@ -3,19 +3,20 @@ packages:
|
||||
- "docs/"
|
||||
|
||||
allowBuilds:
|
||||
esbuild: true
|
||||
sharp: true
|
||||
esbuild: true
|
||||
playwright: true
|
||||
|
||||
onlyBuiltDependencies:
|
||||
- playwright
|
||||
fetchTimeout: 300000
|
||||
fetchRetries: 10
|
||||
|
||||
supportedArchitectures:
|
||||
os:
|
||||
- current
|
||||
- linux
|
||||
cpu:
|
||||
- current
|
||||
- x64
|
||||
libc:
|
||||
- current
|
||||
- glibc
|
||||
|
||||
minimumReleaseAgeExclude:
|
||||
- astro@7.2.9
|
||||
|
||||
Reference in New Issue
Block a user