@zenithbuild/core 0.1.0 → 0.3.1

package/docs/COMMENTS.md

@@ -1,111 +0,0 @@
-# Conventional Comments
-
-Zenith uses [Conventional Comments](https://conventionalcomments.org/) to provide clear, actionable feedback in pull requests.
-
-## Format
-
-```
-<label> [decorations]: <subject>
-
-[discussion]
-```
-
-## 💫 Quick Reference
-### Labels
-
-| Label        | Description                                          | Example Use Case                           |
-|--------------|------------------------------------------------------|-------------------------------------------|
-| **praise**   | Highlight something positive                         | Great implementation, well-documented code |
-| **nitpick**  | Minor suggestions that don't require changes         | Variable naming, minor style preferences   |
-| **suggestion** | Propose improvements to consider                   | Alternative approaches, optimizations      |
-| **issue**    | Highlight problems that need to be resolved          | Bugs, errors, critical problems            |
-| **question** | Ask for clarification or explanation                 | Understanding intent, approach questions   |
-| **thought**  | Share ideas or considerations for the future         | Architectural thoughts, future improvements |
-| **chore**    | Simple tasks like formatting or typos                | Missing semicolons, typos, formatting      |
-
-### Decorations
-
-| Decoration        | Meaning                                              |
-|-------------------|------------------------------------------------------|
-| **(non-blocking)** | Optional feedback - PR can merge without addressing |
-| **(blocking)**    | Must be addressed before merge                       |
-| **(if-minor)**    | Address only if it's a quick fix                     |
-
-## Examples
-
-### Praise
-```
-praise: Excellent error handling here!
-
-This covers all the edge cases I was worried about.
-```
-
-### Nitpick (non-blocking)
-```
-nitpick (non-blocking): Consider renaming `temp` to `processedData`
-
-While `temp` works, a more descriptive name might help future maintainers.
-```
-
-### Suggestion
-```
-suggestion: We could use a Map instead of an Object here for better performance
-
-Since we're doing frequent lookups, a Map would give us O(1) access time
-and better memory characteristics for this use case.
-```
-
-### Issue (blocking)
-```
-issue (blocking): This will throw when `items` is undefined
-
-We need to add a null/undefined check before calling `.map()` on line 42.
-```
-
-### Question
-```
-question: Why are we processing this data twice?
-
-I see similar logic on lines 15 and 78. Is there a reason we can't
-consolidate these operations?
-```
-
-### Thought
-```
-thought: This might be a good candidate for a custom hook in the future
-
-Not for this PR, but as we add more components with similar behavior,
-extracting this pattern could be valuable.
-```
-
-### Chore
-```
-chore (if-minor): Missing semicolon on line 23
-```
-
-## Best Practices
-
-1. **Be specific** - Reference line numbers or code sections
-2. **Be kind** - Remember there's a human on the other side
-3. **Be clear** - Explain the "why" behind your feedback
-4. **Use blocking sparingly** - Only for issues that truly need resolution
-5. **Praise good work** - Positive feedback is valuable!
-
-## Quick Tips for Reviewers
-
-- Start with **praise** for good work
-- Use **suggestion** for most feedback (not blocking unless critical)
-- Reserve **issue (blocking)** for bugs or critical problems
-- Use **question** when you don't understand something
-- Mark style preferences as **nitpick (non-blocking)**
-
-## Quick Tips for Authors
-
-- Don't take **nitpicks** personally - they're optional
-- Ask for clarification on unclear **questions** or **suggestions**
-- Address all **blocking** comments before requesting re-review
-- Thank reviewers for their time and feedback
-
----
-
-**Remember**: The goal is constructive collaboration, not perfection. Use these conventions to make reviews clearer and more productive for everyone.

package/docs/COMMITS.md

@@ -1,36 +0,0 @@
-## TL;DR
-***If you find that this is tanking your productivity just use `feat` or `fix` and always apply `!` if pushing breaking changes***
-
-## Why bother with conventional commits?
-- _The most important reason for us is to simplify/automate SemVer and our Release strategy_
-- For this reason, please prefix all commits with one of the below [Prefixes](#prefixes)
-
-## How does this relate to SemVer?
-- `fix` type commits should be translated to `PATCH` releases.
-- `feat` type commits should be translated to `MINOR` releases.
-- Commits with `BREAKING CHANGE` or `!` (e.g. `feat!: extend parser`) in the commits, regardless of type, should be translated to `MAJOR` releases.
-
-## Prefixes
-| Commit Prefix   | SemVer Equivalent | Example                              |
-| --------------- | ----------------- | ------------------------------------ |
-| fix:            | PATCH - 0.0.n     | fix: html not recognizing state      |
-| feat:           | MINOR - 0.n.0     | feat: phase 2 event loop             |
-| fix!:           | MAJOR - n.0.0     | fix!: html not recognizing state     |
-| feat!:          | MAJOR - n.0.0     | feat!: phase 2 event loop            |
-| BREAKING CHANGE | MAJOR - n.0.0     | fix: BREAKING CHANGE component state |
-| BREAKING-CHANGE | MAJOR - n.0.0     | feat: BREAKING-CHANGE build phase 2  |
-| docs:           | CHANGELOG         | ...                                  |
-| chore:          | CHANGELOG         | ...                                  |
-| style:          | CHANGELOG         | ...                                  |
-| test:           | CHANGELOG         | ...                                  |
-| refactor:       | CHANGELOG         | ...                                  |
-
-### Glossary
-
-- `feat:` - New features
-- `fix:` - Bug fixes
-- `docs:` - Documentation changes
-- `style:` - Code style changes (formatting, no logic change)
-- `refactor:` - Code refactoring
-- `test:` - Adding or updating tests
-- `chore:` - Maintenance tasks

package/docs/CONTRIBUTING.md

@@ -1,116 +0,0 @@
-# 💫 Contributing to Zenith
-## 📌 Prerequisites
-
-> Before you begin, join the [Discord Server](https://discord.gg/T85bBj8T3n) and **ensure you have the following installed**:
-
-- **[Bun](https://bun.sh/)** (v1.0 or later) - Zenith uses Bun as its JavaScript runtime and package manager
-- **[Git](https://git-scm.com/)** - For version control
-
-### Installation
-
-1. **Clone the repository (no fork)**
-   ```ts
-   git clone https://github.com/judahbsullivan/zenith.js.git
-   cd zenith
-   ```
-2. **Install dependencies**
-   ```ts
-   bun install
-   ```
-3. **Build the application** (required first)
-   ```ts
-   bun run build
-   ```
-   This compiles `.zen` files from `app/pages/` into `app/dist/`.
-
-4. **Run the development server**
-   ```ts
-   bun run dev
-
-> **Important**: Use `bun run <script>` to execute npm scripts from package.json. The command `bun build` (without `run`) invokes Bun's built-in bundler, which won't specify our entrypoints by default.
-
-## 🌿 Branching Strategy
-### Option 1: Issue-Driven Development (Preferred)
-
-1. **Create or find an issue** on GitHub that describes the work you want to do
-2. **Create a branch from the issue** directly on GitHub
-   - Branch name format: `{issue-number}-{short-description}`
-   - Example: `33-contributing-md`
-3. **Pull the branch** to your local machine
-   ```ts
-   git fetch origin
-   git checkout 33-contributing-md
-   ```
-
-### Option 2: Feature/Fix Branch
-
-If you're working on something without an existing issue:
-
-1. **Branch from `main`**
-   ```ts
-   git checkout main
-   git pull origin main
-   git checkout -b {prefix}/{short-description}
-   ```
-2. **Use appropriate prefix subfolder** based on the type of change:
-   - `feat/` for new features → MINOR version bump (0.n.0)
-   - `fix/` for bug fixes → PATCH version bump (0.0.n)
-   - `docs/` for documentation changes
-   - `refactor/` for code refactoring
-   - `test/` for adding or updating tests
-   - `chore/` for maintenance tasks
-
-Example: `feat/reactive-state` or `fix/router-navigation`
-
-## 📝 Commit Strategy
-> Zenith follows [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/) for consistent versioning and changelog generation.
-
-### Commit Message Format
-
-```ts
-<type>[optional scope]: <description>
-[optional body]
-[optional footer(s)]
-```
-### Quick Reference
-
-| Prefix   | SemVer Impact | Example                          |
-|----------|---------------|----------------------------------|
-| `fix:`   | PATCH (0.0.n) | `fix: html not recognizing state` |
-| `feat:`  | MINOR (0.n.0) | `feat: add reactive state system` |
-| `feat!:` | MAJOR (n.0.0) | `feat!: change compiler API`      |
-| `fix!:`  | MAJOR (n.0.0) | `fix!: remove deprecated methods` |
-
-**Breaking Changes**: Use `!` after the type or include `BREAKING CHANGE:` in the footer.
-
-**📌 For complete details, see [COMMITS.md](COMMITS.md)**
-
-## 💬 Pull Request Comment Strategy
-> Zenith uses [Conventional Comments](https://conventionalcomments.org/) for clear, actionable PR feedback.
-
-### Comment Format
-```ts
-<label> [decorations]: <subject>
-[discussion]
-```
-### Examples
-```ts
-suggestion (non-blocking): Consider using a more descriptive variable name
-This would improve readability for future maintainers.
-```
-```ts
-issue (blocking): This function will throw an error when input is null
-We need to add null checking before processing.
-```
-
-**📌 For complete details, see [COMMENTS.md](COMMENTS.md)**
-
-## ❓ Questions?
-- Check existing [Issues](https://github.com/judahbsullivan/zenith/issues)
-- Review [README.md](../README.md) for project overview
-- Reach out to maintainers in your PR, Issue or [Discord!](https://discord.gg/T85bBj8T3n)
-
----
-
-**Remember**: Contributing should be enjoyable! Don't hesitate to ask questions if anything is unclear.
-

package/docs/STYLEGUIDE.md

@@ -1,62 +0,0 @@
-# Style Guide
-## Code Style
-- TypeScript only
-- No implicit any
-- Prefer explicit return types for public APIs
-- Avoid magic strings
-## Architectural Rules
-- Compiler decisions > runtime decisions
-- HTML is the source of truth
-- Navigation controls rendering, not components
-- Layouts persist unless explicitly changed
-## Naming Conventions
-- camelCase for variables
-- PascalCase for components
-- kebab-case for files where appropriate
-- `.zenith` for user-facing components
-## API Design Rules
-- No developer flags for runtime behavior
-- Behavior inferred via static analysis
-- Fail loudly at compile time
-## What to Avoid
-- Implicit global state
-- Hidden hydration logic
-- Runtime heuristics
-- JSX-only APIs
-## Guiding Question
-> "Can the compiler decide this instead?"
-If yes — move it out of runtime.
-
-## 🎯 Development Philosophy
-
-- **Simplicity over complexity** - Zenith aims to be intuitive and straightforward
-- **HTML-first** - HTML is the source of truth
-- **Consistency** - Follow established patterns in the codebase
-- **Iteration speed** - Don't let perfect be the enemy of good
-
-## 🧪 Testing Your Changes
-
-Before submitting a PR:
-
-1. **Build the application** to compile your changes:
-   ```bash
-   bun run build
-   ```
-
-2. **Run the dev server** and verify your changes work:
-   ```bash
-   bun run dev
-   ```
-   Visit `http://localhost:3000` to test.
-
-3. **Format your code**:
-   ```bash
-   bun run format
-   ```
-
-4. **Check formatting** (optional):
-   ```bash
-   bun run format:check
-   ```
-
-> **Note**: Use `bun run <script>` for npm scripts. Plain `bun build` invokes Bun's bundler, not the project build script.

package/scripts/webhook-proxy.ts

@@ -1,213 +0,0 @@
-#!/usr/bin/env bun
-/**
- * GitHub to Discord Webhook Proxy
- * 
- * This server receives GitHub webhook events and formats them for Discord.
- * 
- * Usage:
- *   1. Add DISCORD_WEBHOOK_URL to .env file (or export as environment variable)
- *   2. Run: bun scripts/webhook-proxy.ts
- *   3. Point GitHub webhook to: http://your-server:3001/webhook
- * 
- * Note: Bun automatically loads .env files from the project root
- */
-
-import { serve } from "bun";
-
-const DISCORD_WEBHOOK_URL = process.env.DISCORD_WEBHOOK_URL;
-
-if (!DISCORD_WEBHOOK_URL) {
-  console.error("❌ Error: DISCORD_WEBHOOK_URL environment variable is required");
-  console.error("   Set it in .env file: DISCORD_WEBHOOK_URL='https://discord.com/api/webhooks/...'");
-  console.error("   Or export it: export DISCORD_WEBHOOK_URL='https://discord.com/api/webhooks/...'");
-  process.exit(1);
-}
-
-const PORT = process.env.PORT || 3001;
-
-interface GitHubIssueEvent {
-  action: string;
-  issue: {
-    number: number;
-    title: string;
-    body: string;
-    html_url: string;
-    state: string;
-    labels: Array<{ name: string; color: string }>;
-    user: {
-      login: string;
-      avatar_url: string;
-    };
-  };
-  repository: {
-    name: string;
-    full_name: string;
-    html_url: string;
-  };
-}
-
-function formatIssueForDiscord(event: GitHubIssueEvent): any {
-  const { issue, repository, action } = event;
-  
-  // Determine color based on action
-  let color = 0x3498db; // Blue (default)
-  if (action === "opened") color = 0x2ecc71; // Green
-  if (action === "closed") color = 0xe74c3c; // Red
-  if (action === "reopened") color = 0xf39c12; // Orange
-  
-  // Format labels
-  const labels = issue.labels.map(l => `\`${l.name}\``).join(" ") || "*No labels*";
-  
-  // Truncate body if too long
-  let description = issue.body || "*No description*";
-  if (description.length > 1000) {
-    description = description.substring(0, 1000) + "...";
-  }
-  
-  // Format action text
-  const actionText: Record<string, string> = {
-    opened: "📝 New Issue Created",
-    closed: "✅ Issue Closed",
-    reopened: "🔄 Issue Reopened",
-    edited: "✏️ Issue Edited",
-    assigned: "👤 Issue Assigned",
-    unassigned: "👤 Issue Unassigned",
-    labeled: "🏷️ Label Added",
-    unlabeled: "🏷️ Label Removed",
-  };
-  
-  const title = actionText[action] || `📋 Issue ${action}`;
-  
-  return {
-    embeds: [
-      {
-        title: title,
-        description: `**${issue.title}**`,
-        url: issue.html_url,
-        color: color,
-        fields: [
-          {
-            name: "Issue #",
-            value: `#${issue.number}`,
-            inline: true,
-          },
-          {
-            name: "State",
-            value: issue.state,
-            inline: true,
-          },
-          {
-            name: "Labels",
-            value: labels,
-            inline: false,
-          },
-          {
-            name: "Description",
-            value: description,
-            inline: false,
-          },
-        ],
-        author: {
-          name: issue.user.login,
-          icon_url: issue.user.avatar_url,
-        },
-        footer: {
-          text: repository.full_name,
-        },
-        timestamp: new Date().toISOString(),
-      },
-    ],
-  };
-}
-
-async function sendToDiscord(payload: any): Promise<Response> {
-  const response = await fetch(DISCORD_WEBHOOK_URL!, {
-    method: "POST",
-    headers: {
-      "Content-Type": "application/json",
-    },
-    body: JSON.stringify(payload),
-  });
-  
-  if (!response.ok) {
-    const text = await response.text();
-    throw new Error(`Discord webhook failed: ${response.status} ${text}`);
-  }
-  
-  return response;
-}
-
-serve({
-  port: PORT,
-  async fetch(req) {
-    const url = new URL(req.url);
-    
-    // Health check endpoint
-    if (url.pathname === "/health") {
-      return new Response(JSON.stringify({ status: "ok" }), {
-        headers: { "Content-Type": "application/json" },
-      });
-    }
-    
-    // Webhook endpoint
-    if (url.pathname === "/webhook" && req.method === "POST") {
-      try {
-        const githubEvent = req.headers.get("x-github-event");
-        const signature = req.headers.get("x-hub-signature-256");
-        
-        if (!githubEvent) {
-          return new Response(
-            JSON.stringify({ error: "Missing x-github-event header" }),
-            { status: 400, headers: { "Content-Type": "application/json" } }
-          );
-        }
-        
-        // Only process issue events
-        if (githubEvent !== "issues" && githubEvent !== "issue_comment") {
-          return new Response(
-            JSON.stringify({ message: `Ignoring event: ${githubEvent}` }),
-            { status: 200, headers: { "Content-Type": "application/json" } }
-          );
-        }
-        
-        const body = await req.json();
-        
-        // Format for Discord
-        let discordPayload;
-        if (githubEvent === "issues") {
-          discordPayload = formatIssueForDiscord(body as GitHubIssueEvent);
-        } else {
-          // Handle issue comments if needed
-          return new Response(
-            JSON.stringify({ message: "Issue comments not yet implemented" }),
-            { status: 200, headers: { "Content-Type": "application/json" } }
-          );
-        }
-        
-        // Send to Discord
-        await sendToDiscord(discordPayload);
-        
-        console.log(`✅ Sent ${githubEvent} event to Discord: ${body.issue?.title || "N/A"}`);
-        
-        return new Response(
-          JSON.stringify({ success: true, event: githubEvent }),
-          { status: 200, headers: { "Content-Type": "application/json" } }
-        );
-      } catch (error: any) {
-        console.error("❌ Error processing webhook:", error);
-        return new Response(
-          JSON.stringify({ error: error.message }),
-          { status: 500, headers: { "Content-Type": "application/json" } }
-        );
-      }
-    }
-    
-    return new Response("Not Found", { status: 404 });
-  },
-});
-
-console.log(`🚀 GitHub to Discord webhook proxy running on port ${PORT}`);
-console.log(`📡 Webhook endpoint: http://localhost:${PORT}/webhook`);
-console.log(`💚 Health check: http://localhost:${PORT}/health`);
-console.log(`\n⚠️  Make sure to set DISCORD_WEBHOOK_URL environment variable`);
-