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 [email protected]

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

I recently shipped ArchUnitTS, an open source architecture testing library for TypeScript / JavaScript.

There are already some tools in this space, so let me explain why I built another one.

What I wanted was not just import linting or dependency visualization. I wanted actual architecture tests that live in the normal test suite and run in CI, similar in spirit to ArchUnit on the JVM side.

So I built ArchUnitTS.

With it, you can test things like:

• forbidden dependencies between layers
• circular dependencies
• naming conventions
• architecture slices
• UML / PlantUML conformance
• code metrics like cohesion, coupling, instability, etc.
• custom architecture rules if the built-ins are not enough

Simple layered architecture example:

``` it('presentation layer should not depend on database layer', async () => { const rule = projectFiles() .inFolder('src/presentation/') .shouldNot() .dependOnFiles() .inFolder('src/database/');

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

I wanted it to integrate naturally into existing setups instead of forcing people into a separate workflow. So it works with normal test pipelines and supports frameworks like Jest, Vitest, Jasmine, Mocha, etc.

Maybe a detail, but ane thing that mattered a lot to me is avoiding false confidence. For example, with some architecture-testing approaches, if you make a mistake in a folder pattern, the rule may effectively run against 0 files and still pass. That’s pretty dangerous. ArchUnitTS detects these “empty tests” by default and fails them, which IMO is much safer. Other libraries lack this unfortunately.

Curious about any type of feedback!!

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

PS: I also made a 20-minute live coding demo on YT: https://www.youtube.com/watch?v=-2FqIaDUWMQ