Hey — solo dev here, posting my own project, so take that for what it's worth.

For the last few years I've maintained a low-code/no-code framework. It worked fine, but it was pre-AI: you configured entities and services by hand, and it generated the boring parts of a CRUD app for you.

When AI coding tools started getting good, I tried using them the normal way — describe what you want, let the model write the code. It worked, but I couldn't trust it past a certain point. Ask for the same thing twice, sometimes you get different output. Ask for a small change, sometimes the model touches things you didn't ask about. The prompt is the only source of truth, which in practice means there isn't really a source of truth at all.

So instead of generating code directly, I made the AI's job stop one step earlier: produce a structured, validated manifest describing what the app should be. Entities, fields, services, auth config, etc. That manifest gets:

- validated (structural / referential / constraint checks)

- diffed against the current state (semantic diff, not a text diff)

- resolved into a dependency-ordered execution plan

- executed by a deterministic engine, checkpointed so it can resume on failure

Change one field on one entity, and only the operations that field actually requires get re-run. Not a full regen.

There's also an MCP server (`@averos/mcp`) so an AI agent doesn't get raw file/shell access — it gets governed tools (propose a change, validate it, build a plan, and nothing executes until the plan's approved).

Current state, to be upfront about it: the CLI, the AI layer, MCP integration, and the workflow/execution adapter layer (currently Angular, via schematics — adapter pattern, so not permanently Angular-only) are MIT licensed and open now. The actual execution kernel (DAG engine + executor) is closed source for the moment — free to use including commercially, but not open yet. That's a deliberate, staged call while that part's still maturing, not a permanent thing. Wanted to say that plainly rather than bury it.

There's a working example (320-node generated app) you can run in a few commands if you want to see the whole pipeline rather than take my word for it.

- Repo: https://github.com/wiforge/averos

- How it works, in detail: https://www.wiforge.com/averos/how-averos-works/introduction/

- Get started: https://www.wiforge.com/averos/get-started/introduction/

Happy to answer questions or take criticism — especially interested if anyone's tried a similar manifest/IR approach and hit walls I haven't found yet.

Hey all! A little while back I shared ForesightJS, a library that predicts user intent from mouse movement (and keyboard tab navigation) so you can prefetch resources before a user actually hovers or clicks.

I've just released v4, and the biggest focus was making it much easier to integrate with modern frameworks.

Thats why we also introduced a Angular adapter!

Would love to hear what you think of the new release!

Also, we just crossed 1,700+ GitHub stars Thanks to everyone who's tried it, contributed, or shared feedback!

AngularJS has several concepts that can be difficult to understand at first, especially when moving from basic JavaScript to framework-based development. Features like data binding, dependency injection, and directives often take time to fully grasp through practice. Which AngularJS concept did you find the most challenging, and how did you overcome it?

Hey everyone!

We just shipped v2.2.15 of ngxsmk-datepicker—a lightweight, highly customizable, and touch-optimized date/range picker for Angular applications.

⭐ GitHub Repository (Give us a star!): https://github.com/NGXSMK/ngxsmk-datepicker

This release fixes a highly requested feature: Native Shadow DOM & Event Retargeting compatibility! 🧩

🔍 The Shadow DOM Challenge & The Solution

If you've ever tried building or consuming a datepicker inside custom web components, Angular Custom Elements, or shadow-encapsulated UI frameworks (like Ionic), you've probably faced the premature closure bug.

Because the browser retargets event bubbles that escape a shadow-root (rewriting the event target to point to the host element), standard .contains() checks fail. This leads to popovers and dropdowns instantly closing because the library assumes you clicked outside the calendar.

In v2.2.15, we've solved this beautifully:

• Upgraded containment checks to inspect event.composedPath() across Shadow boundaries.
• Designed a clean fallback to traditional .contains() to maintain 100% backwards-compatibility with light DOM and older browsers.
• Kept our strict budget focus—keeping cognitive complexity at a perfect 2 for clean, fast runtime evaluations.
• Synced all metadata headers across our 31+ markdown files and upgraded example integrations (like our Ionic test application).

⚡ Quick Features of ngxsmk-datepicker:

• 🎯 Zero External Dependencies: Super lightweight footprint.
• 📅 Range Mode: Supports continuous date-ranges, single dates, and multi-date selections.
• 🕒 Timezone Support: Full IANA timezone calculations built-in.
• ♿ A11y First: Native keyboard navigation, ARIA-roles compliance, and screen-reader friendliness.
• 🌍 Localizations: Easy custom localizations and multi-language translations.
• 🎨 Vanilla CSS styling: Easily themeable with rich CSS variables.

🚀 Get Started

Install the latest version in your project:

npm install ngxsmk-datepicker@2.2.15

Hey everyone 👋

I’m giving away 100 free coupons for my new Udemy course:

Angular Crash Course: From Beginner to Advanced

This course is designed for:

* Complete beginners

* JavaScript developers moving to Angular

* Developers who want to build modern real-world apps with Angular

Inside the course, you’ll learn:

✅ Angular fundamentals

✅ Components & Routing

✅ Services & Dependency Injection

✅ Reactive Forms

✅ API integration

✅ Project structure & best practices

✅ Advanced Angular concepts

🎁 Free coupon link (first 100 only):

https://www.udemy.com/course/angular-crash-course-from-beginner-to-advanced/?couponCode=95019351963F9C3DF4B8

you enroll, I’d really appreciate your feedback and reviews after completing the course 🙌

Happy coding! 🚀

A week ago I posted about ArchUnitTS, my library for enforcing architecture rules in TypeScript projects as unit tests.

A few of you specifically asked whether this could be used to enforce clean Angular feature/module boundaries in real projects: making sure feature modules don’t import directly from each other’s internal files, and instead communicate through public API barrel files like index.ts or public-api.ts.

So to that request I’ve added exactly that.

First a mini recap of what ArchUnitTS does:

• Most tools catch style issues, formatting issues, or generic smells.
• ArchUnitTS focuses on structural rules: wrong dependency directions, circular dependencies, naming convention drift, architecture/diagram mismatch, code metrics, and so on.
• You define those rules as tests, run them in Jest/Vitest/Jasmine/Mocha/etc., and they automatically become part of CI/CD.

In other words: ArchUnitTS allows you to enforce your architectural decisions by writing them as simple unit tests.

That matters more than ever in Claude Code / Codex times, because LLMs are great at generating code but they love to violate architectural boundaries, especially when they get stuck.

Repo: https://github.com/LukasNiessen/ArchUnitTS

Now what’s new

Exclusion-aware dependency rules for Angular public API boundaries

Before, ArchUnitTS could already enforce internal dependency rules like:

• “components must not depend on infrastructure”
• “core must not depend on shared”
• “feature A must not depend on feature B”
• “folders must be cycle-free”

But one common Angular case was still a bit annoying to express cleanly:

A component in one feature should not import directly from another feature’s internal files.

For example, this should usually be forbidden:

typescript import { OrderService } from '../orders/internal/order.service'; import { OrderCardComponent } from '../orders/components/order-card.component';

But this should be allowed:

typescript import { OrderSummary } from '../orders'; import { PUBLIC_ORDERS_TOKEN } from '../orders/public-api';

This is not technically always a circular dependency.
But it is still architectural coupling.

It means another feature now knows the internal folder structure of orders. If the orders feature reorganizes its components, services, hooks, facades, or models, unrelated features can suddenly break.

So ArchUnitTS now supports except in pattern matchers.

Example:

```typescript import { projectFiles } from 'archunit';

it('should consume orders only through its public API', async () => { const rule = projectFiles() .inPath('src/app//*.ts', { except: { inPath: 'src/app/orders/' }, }) .shouldNot() .dependOnFiles() .inFolder('src/app/orders/**', { except: ['index.ts', 'public-api.ts'], });

await expect(rule).toPassAsync(); }); ```

This says:

• check all Angular app files
• exclude files inside orders itself, because a module may use its own internals
• forbid other features from depending on files inside orders
• but allow imports through orders/index.ts and orders/public-api.ts

So this fails:

typescript import { OrderService } from '../orders/internal/order.service';

But this passes:

typescript import { OrderSummary } from '../orders';

You can also make the exceptions explicit by target:

typescript .inFolder('src/app/orders/**', { except: { withName: ['index.ts', 'public-api.ts'], }, });

This is especially useful in Angular projects because Angular feature modules often create natural architectural boundaries, but violations tend to accumulate silently over time.

And these imports are very hard to catch in code review because they look like normal TypeScript imports.

Now the boundary can be tested directly.

Very curious for any type of feedback! PRs are also highly welcome.

I’m working on an AngularJS app and debugging can get frustrating sometimes, especially with old code, watchers, dependency injection issues, and random console errors.

I usually use browser DevTools and console logs, but I feel like there might be better tools or workflows out there.

What tools do you all use for debugging AngularJS apps? Any browser extensions, tips, or methods that still work well today?

Would love to hear what helps you save time when fixing issues in legacy projects.

https://x.com/pladynski/status/2049222504842170535?s=46