Compare commits
3
Commits
| Author | SHA1 | Date | |
|---|---|---|---|
 Ninosaurier
|
97d6e652c8 | ||
|
Ninosaurier
|
3bb9c1f6fb | ||
|
Ninosaurier
|
4033aba10a |
@@ -0,0 +1,37 @@
|
||||
<!-- markdownlint-disable MD041 -->
|
||||
## Goal
|
||||
|
||||
<!-- One sentence: what should this issue achieve? -->
|
||||
|
||||
## Description
|
||||
|
||||
<!-- Context and background: why is this issue necessary?
|
||||
What is the current state, and what is missing or needs to be done? -->
|
||||
|
||||
## Steps to Reproduce
|
||||
|
||||
<!-- Only relevant for bugs — remove this section for tasks/features.
|
||||
1. Go to '...'
|
||||
2. Click on '...'
|
||||
3. See error -->
|
||||
|
||||
## Expected Behaviour
|
||||
|
||||
<!-- Only relevant for bugs — what should have happened? -->
|
||||
|
||||
## Actual Behaviour
|
||||
|
||||
<!-- Only relevant for bugs — what happened instead? -->
|
||||
|
||||
## Tasks
|
||||
|
||||
- [ ] ...
|
||||
- [ ] ...
|
||||
- [ ] ...
|
||||
- [ ] Update the related parts of the documentation
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- ...
|
||||
- ...
|
||||
- ...
|
||||
@@ -0,0 +1,34 @@
|
||||
<!-- markdownlint-disable MD041 -->
|
||||
## Description
|
||||
|
||||
<!-- What does this PR change and why? -->
|
||||
|
||||
## Related Issue
|
||||
|
||||
<!-- Closes #... / Relates to #... -->
|
||||
|
||||
## Type of Change
|
||||
|
||||
- [ ] Bug fix
|
||||
- [ ] New feature
|
||||
- [ ] Refactoring (no functional changes)
|
||||
- [ ] Documentation
|
||||
- [ ] Tests
|
||||
|
||||
## Changes
|
||||
|
||||
- ...
|
||||
- ...
|
||||
- ...
|
||||
|
||||
## How Has This Been Tested?
|
||||
|
||||
<!-- Describe how you verified your changes (unit tests, manual testing, etc.) -->
|
||||
|
||||
## Checklist
|
||||
|
||||
- [ ] Code follows the project's style guidelines
|
||||
- [ ] Self-review of the code has been performed
|
||||
- [ ] Tests have been added/updated and pass locally
|
||||
- [ ] Documentation has been updated where necessary
|
||||
- [ ] No new warnings or errors introduced
|
||||
@@ -194,4 +194,4 @@ The Business Architecture defines:
|
||||
- Strict separation of responsibilities
|
||||
- Accessibility as cross-cutting concern
|
||||
|
||||
*(Ensures consistency with Phase C decisions)*
|
||||
*(Ensures consistency with Phase C _"Information Systems Architecture"_ decisions)*
|
||||
@@ -9,9 +9,12 @@ import { Aside } from '@astrojs/starlight/components';
|
||||
|
||||
## 1. Overview
|
||||
|
||||
This Application Architecture defines how LUNA Charts is structured at the application level. It describes the internal processing model, developer interaction boundaries, system layers, and architectural style used to ensure accessible, consistent, and predictable chart rendering.
|
||||
This Application Architecture defines how LUNA Charts is structured at the application level.
|
||||
It describes the internal processing model, developer interaction boundaries, system layers, and architectural
|
||||
style used to ensure accessible, consistent, and predictable chart rendering.
|
||||
|
||||
LUNA Charts is designed as a declarative, component-based charting library with a controlled internal processing pipeline and strict input boundaries.
|
||||
LUNA Charts is designed as a declarative, component-based charting library with a controlled internal processing pipeline
|
||||
and strict input boundaries.
|
||||
|
||||
## 2. Architectural Style
|
||||
|
||||
@@ -62,7 +65,7 @@ Developers cannot:
|
||||
|
||||
## 4. System Boundary Model
|
||||
|
||||
LUNA Charts exposes a strict system boundary:
|
||||
LUNA Charts exposes a strict system boundary.
|
||||
|
||||
### Allowed Inputs
|
||||
|
||||
@@ -92,15 +95,18 @@ Receives component input, accepts data and configuration, and normalizes incomin
|
||||
|
||||
### 5.2 Resilience & Validation Layer
|
||||
|
||||
Validates input data integrity, detects missing or invalid values, triggers fallback behavior if necessary, and emits warnings for developer feedback.
|
||||
Validates input data integrity, detects missing or invalid values, triggers fallback behavior if necessary,
|
||||
and emits warnings for developer feedback.
|
||||
|
||||
### 5.3 Configuration Resolution Layer
|
||||
|
||||
Merges user configuration with default values, resolves themes, labels, and styling parameters, and applies library-provided defaults when needed.
|
||||
Merges user configuration with default values, resolves themes, labels, and styling parameters, and applies
|
||||
library-provided defaults when needed.
|
||||
|
||||
### 5.4 Accessibility Enforcement Layer
|
||||
|
||||
Applies accessibility rules and guidance mechanisms intended to support WCAG-compliant chart implementations, generates ARIA attributes, validates known accessibility constraints, and provides runtime warnings and developer feedback.
|
||||
Applies accessibility rules and guidance mechanisms intended to support WCAG-compliant chart implementations,
|
||||
generates ARIA attributes, validates known accessibility constraints, and provides runtime warnings and developer feedback.
|
||||
|
||||
<Aside type="tip">
|
||||
Accessibility enforcement is a cross-cutting concern applied across all layers — see [Section 4](#4-system-boundary-model).
|
||||
@@ -108,7 +114,8 @@ Applies accessibility rules and guidance mechanisms intended to support WCAG-com
|
||||
|
||||
### 5.5 Rendering Layer
|
||||
|
||||
Transforms processed data into visual representations, generates SVG or Canvas output, and produces the final chart visualization.
|
||||
Transforms processed data into visual representations, generates SVG or Canvas output, and produces
|
||||
the final chart visualization.
|
||||
|
||||
## 6. Chart Type Model
|
||||
|
||||
@@ -162,7 +169,8 @@ Configuration is merged with system defaults during the processing pipeline.
|
||||
|
||||
## 9. Technology-Agnostic Design
|
||||
|
||||
This Application Architecture does not assume a specific frontend framework but is compatible with modern web ecosystems such as:
|
||||
This Application Architecture does not assume a specific frontend framework but is compatible with
|
||||
modern web ecosystems such as:
|
||||
|
||||
- React
|
||||
- Vue
|
||||
|
||||
@@ -7,7 +7,9 @@ sidebar:
|
||||
|
||||
import { Aside } from '@astrojs/starlight/components';
|
||||
|
||||
LUNA Charts is a reusable, developer-friendly charting library that makes accessible, WCAG-oriented data visualization the default rather than an afterthought. Since chart accessibility is often added late or skipped entirely, LUNA Charts bakes it into every component from the start.
|
||||
LUNA Charts is a reusable, developer-friendly charting library that makes accessible,
|
||||
WCAG-oriented data visualization the default rather than an afterthought. Since chart accessibility is often added
|
||||
late or skipped entirely, LUNA Charts bakes it into every component from the development start.
|
||||
|
||||
## Documented with the ADM
|
||||
|
||||
|
||||
@@ -9,9 +9,12 @@ import { Aside } from '@astrojs/starlight/components';
|
||||
|
||||
## 1. Overview
|
||||
|
||||
This Technology Architecture defines the underlying technology decisions for LUNA Charts. It describes the runtime environment, rendering technology, programming language, distribution model, testing strategy, and release pipeline.
|
||||
This Technology Architecture defines the underlying technology decisions for LUNA Charts.
|
||||
It describes the runtime environment, rendering technology, programming language, distribution model,
|
||||
testing strategy, and release pipeline.
|
||||
|
||||
LUNA Charts is designed as a modern, accessibility-first charting library optimized for web environments, focusing on performance, consistency, and WCAG-oriented rendering behavior.
|
||||
LUNA Charts is designed as a modern, accessibility-first charting library optimized for web environments,
|
||||
focusing on performance, consistency, and WCAG-oriented rendering behavior.
|
||||
|
||||
## 2. Rendering Technology
|
||||
|
||||
@@ -145,7 +148,9 @@ LUNA Charts follows a multi-layer quality assurance model.
|
||||
- **Not required for patch releases** (bug fixes, internal refactors with no user-facing change)
|
||||
|
||||
<Aside type="caution" title="Release Gate Policy">
|
||||
Automated testing (unit, accessibility, linting, visual regression) is a **blocking condition for every release**. Usability testing is a **blocking condition for minor and major releases**, but is skipped for patch releases to avoid delaying critical fixes.
|
||||
Automated testing (unit, accessibility, linting, visual regression) is a **blocking condition for every release**.
|
||||
Usability testing is a **blocking condition for minor and major releases**, but is skipped for patch releases to
|
||||
avoid delaying critical fixes.
|
||||
</Aside>
|
||||
|
||||
### 6.6 Test Execution Environment
|
||||
@@ -229,7 +234,7 @@ LUNA Charts targets modern web environments.
|
||||
- No plugin or extension system
|
||||
- Multi-layer testing strategy with release gating
|
||||
- Containerized, reproducible test execution environment for browser and accessibility tests
|
||||
- Open-source distribution via GitHub and npm
|
||||
- Open-source distribution via Gitea and npm
|
||||
- Modern browser and mobile-first runtime strategy
|
||||
|
||||
## 10. Trade-offs
|
||||
@@ -253,10 +258,12 @@ LUNA Charts targets modern web environments.
|
||||
|
||||
## 11. Change Log
|
||||
|
||||
This document reflects a refined Technology Architecture based on iterative architectural decisions across Phase A (Vision), Phase B (Business Architecture), and Phase C (Application Architecture). Key clarifications introduced in this phase:
|
||||
This document reflects a refined Technology Architecture based on iterative architectural decisions across Phase A (Vision),
|
||||
Phase B (Business Architecture), and Phase C (Application Architecture). Key clarifications introduced in this phase:
|
||||
|
||||
- SVG confirmed as the only rendering technology due to accessibility requirements
|
||||
- Accessibility is treated as a cross-cutting concern supported by type safety, runtime validation, and internal quality assurance (not a standalone engine)
|
||||
- Accessibility is treated as a cross-cutting concern supported by type safety, runtime validation, and internal
|
||||
quality assurance (not a standalone engine)
|
||||
- Framework neutrality enforced through adapter-based architecture
|
||||
- Distribution model defined as a single-package open-source release via npm and GitHub
|
||||
- Testing strategy defined as a multi-layer quality gate system (unit, accessibility, linting, visual regression)
|
||||
@@ -266,16 +273,20 @@ This document reflects a refined Technology Architecture based on iterative arch
|
||||
|
||||
**Reason**
|
||||
|
||||
Component and browser tests are executed inside a Docker-based Playwright environment (`Dockerfile.test`, `docker-compose.test.yaml`), which was introduced during implementation but had not yet been reflected in this document.
|
||||
Component and browser tests are executed inside a Docker-based Playwright
|
||||
environment (`Dockerfile.test`, `docker-compose.test.yaml`), which was introduced during implementation but had not yet been
|
||||
reflected in this document.
|
||||
|
||||
**Changes**
|
||||
|
||||
- Added Section 6.6 "Test Execution Environment" describing the containerized Playwright setup used for local development and CI
|
||||
- Added Section 6.6 "Test Execution Environment" describing the containerized Playwright setup used for local
|
||||
development and CI
|
||||
- Added "Containerized, reproducible test execution environment" to Section 9 "Key Architectural Decisions"
|
||||
|
||||
**Impact**
|
||||
|
||||
This clarifies an already-implemented part of the testing strategy (Section 6) and does not change any other architectural decision in this document.
|
||||
This clarifies an already-implemented part of the testing strategy (Section 6) and does not change any
|
||||
other architectural decision in this document.
|
||||
|
||||
### 2026-08-04 – CI uses a prebuilt test image instead of rebuilding per run
|
||||
|
||||
|
||||
@@ -5,13 +5,22 @@ sidebar:
|
||||
order: 0
|
||||
---
|
||||
|
||||
LUNA Charts is an open-source charting library built with a strong focus on **accessibility**, **developer experience**, and **long-term maintainability**.
|
||||
LUNA Charts is an open-source charting library built with a strong focus on **accessibility**, **developer experience**, and
|
||||
**long-term maintainability**.
|
||||
|
||||
The project was created because many existing charting libraries provide excellent visualizations, but often treat accessibility, architecture, and maintainability as secondary concerns.
|
||||
The project was created because many existing charting libraries provide excellent visualizations but often
|
||||
treat accessibility as a secondary concern. Furthermore, a lot of teams have a lack of accessibility awareness,
|
||||
and accessibility features are often pushed to the end of the project.
|
||||
|
||||
LUNA Charts takes a different approach.
|
||||
|
||||
Instead of starting with code, the project started with an **architecture-first process**. The entire foundation—including business goals, technical architecture, governance, and architectural decisions—was designed before implementation began.
|
||||
Instead of focusing on becoming a big library with numerous chart-creation functions, this project concentrates
|
||||
on ease of use and chart modification, with accessibility playing a major role throughout the entire development process.
|
||||
LUNA-Charts is open-source software.
|
||||
This guarantees that everyone can use and modify it. We want to make the world more accessible for everyone.
|
||||
|
||||
Furthermore, we focus on an **architecture-first process**. The entire foundation—including
|
||||
business goals, technical architecture, governance, and architectural decisions—was designed before implementation began.
|
||||
|
||||
## Project Goals
|
||||
|
||||
@@ -26,11 +35,9 @@ LUNA Charts aims to provide a charting library that is:
|
||||
|
||||
## Current Project Status
|
||||
|
||||
The project is currently in the **Groundwork** phase.
|
||||
|
||||
At this stage, the architecture, repository structure, development workflow, and governance model are being established before implementing the first chart components.
|
||||
|
||||
Although no production-ready charts are available yet, the project documentation already reflects the long-term vision and architectural direction.
|
||||
The project is currently in the **First Proof of Concept (v0.3.0)** phase.
|
||||
We validate the core technical and accessibility assumptions of the library through a first working implementation.
|
||||
The goal is to prove that the chosen architecture actually works in practice before committing to a broader component set.
|
||||
|
||||
## Learn More
|
||||
|
||||
|
||||
@@ -5,7 +5,8 @@ sidebar:
|
||||
order: 1
|
||||
---
|
||||
|
||||
LUNA Charts follows a modular repository structure that separates the chart library from its documentation while keeping all project artifacts within a single repository.
|
||||
LUNA Charts follows a modular repository structure that separates the chart library from its documentation while keeping
|
||||
all project artifacts within a single repository.
|
||||
|
||||
```text
|
||||
luna-charts/
|
||||
@@ -51,31 +52,38 @@ It serves as the **Single Point of Truth (SPOT)** for:
|
||||
- Project governance
|
||||
- User documentation
|
||||
|
||||
The documentation is rendered using **Starlight**, but the Markdown content remains the authoritative source.
|
||||
The documentation is rendered using **Astro and Starlight**, but the Markdown content remains the authoritative source.
|
||||
|
||||
---
|
||||
|
||||
## examples/
|
||||
|
||||
Example applications demonstrating how to integrate LUNA Charts with supported frontend frameworks will be added here in future iterations.
|
||||
Example applications demonstrating how to integrate LUNA Charts with supported frontend frameworks
|
||||
will be added here in future iterations.
|
||||
|
||||
Examples may include:
|
||||
|
||||
- Vanilla JavaScript
|
||||
- React
|
||||
- Angular
|
||||
- Vue
|
||||
|
||||
Right now, we are working on version 0.3.0, implementing a first proof of concept.
|
||||
The first Minimum Viable Product will be launched with version 1.0.0.
|
||||
|
||||
---
|
||||
|
||||
## .gitea/
|
||||
|
||||
- Gitea Actions
|
||||
- Issue templates
|
||||
- Pull request templates
|
||||
- Community workflows
|
||||
|
||||
## .github/
|
||||
|
||||
Contains project automation such as:
|
||||
|
||||
- GitHub Actions
|
||||
- Issue templates
|
||||
- Pull request templates
|
||||
- Community workflows
|
||||
- Code of Conduct
|
||||
|
||||
---
|
||||
|
||||
@@ -83,6 +91,7 @@ Contains project automation such as:
|
||||
|
||||
LUNA Charts is maintained as a **pnpm workspace**.
|
||||
|
||||
This structure allows multiple packages and supporting projects to evolve together while sharing a consistent toolchain and development workflow.
|
||||
This structure allows multiple packages and supporting projects to evolve together while sharing a consistent
|
||||
toolchain and development workflow.
|
||||
|
||||
As the project grows, additional packages or tooling may be introduced without changing the overall repository organization.
|
||||
@@ -7,7 +7,9 @@ sidebar:
|
||||
|
||||
LUNA Charts follows an **architecture-first** development approach.
|
||||
|
||||
Instead of implementing features immediately, the project establishes a solid architectural and organizational foundation before writing production code. This ensures long-term maintainability, consistent quality, and transparent decision-making.
|
||||
Instead of implementing features immediately, the project establishes a solid architectural and organizational
|
||||
foundation before writing production code. This ensures long-term maintainability, consistent quality, and
|
||||
transparent decision-making.
|
||||
|
||||
---
|
||||
|
||||
@@ -20,7 +22,7 @@ Instead of implementing features immediately, the project establishes a solid ar
|
||||
Completed work includes:
|
||||
|
||||
- **Repository structure:** Standardized layout for code, configurations, and assets.
|
||||
- \*\*Development workflow: Definition of branching strategies, commit rules, and review processes.
|
||||
- **Development workflow:** Definition of branching strategies, commit rules, and review processes.
|
||||
- **Architecture documentation (TOGAF ADM):** Architecture framework set up according to the TOGAF standard.
|
||||
- **Architecture Decision Records (ADRs 1-5):** System established for transparent documentation of architectural decisions.
|
||||
- **Project governance:** Defined roles, responsibilities, and decision-making processes.
|
||||
@@ -102,6 +104,5 @@ Future work may include:
|
||||
|
||||
## Long-Term Vision
|
||||
|
||||
LUNA Charts aims to become an accessible, framework-independent charting library that combines modern Web Components with a transparent architecture and a sustainable open-source development model.
|
||||
|
||||
Every milestone builds upon the architectural foundation established during the Groundwork phase.
|
||||
LUNA Charts aims to become an accessible, framework-independent charting library that combines modern Web Components with a
|
||||
transparent architecture and a sustainable open-source development model.
|
||||
|
||||
Reference in New Issue
Block a user