u/trolleid

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 useful for React feature-folder architectures: keeping feature internals private, while allowing other features to import only from public entry points like index.ts.

So to that request I’ve added exclusion-aware dependency rules.

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 React feature boundaries

A lot of React codebases use feature folders:

src/
  features/
    orders/
      index.ts
      components/
        OrderCard.tsx
      hooks/
        useOrders.ts
      api/
        orderClient.ts
    customers/
      CustomerPage.tsx

Usually the intended dependency is:

import { OrderCard, useOrders } from '../orders';

But over time, imports like this start appearing:

import { useOrders } from '../orders/hooks/useOrders';
import { orderClient } from '../orders/api/orderClient';

That works technically, but it bypasses the feature’s public API.

Now customers knows that orders has a hooks folder, an api folder, and a specific internal file layout.

If orders reorganizes itself later, unrelated features break.

So ArchUnitTS now lets you express this kind of boundary with except:

import { projectFiles } from 'archunit';

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

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

This says:

• check files inside src/features
• ignore the orders feature itself
• forbid other features from importing into orders internals
• allow orders/index.ts as the public API

So this fails:

import { useOrders } from '../orders/hooks/useOrders';
import { orderClient } from '../orders/api/orderClient';

But this passes:

import { useOrders, OrderCard } from '../orders';

You can also allow multiple public entry points:

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

Or exclude multiple features/folders from the source side:

.inPath('src/features/**/*.ts?(x)', {
  except: {
    inPath: [
      'src/features/orders/**',
      'src/features/generated/**',
      'src/features/testing/**',
    ],
  },
});

This is the kind of architectural rule that is hard to enforce in code review because the bad import still looks like normal TypeScript.

But once it is a unit test, it becomes part of CI/CD.

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

I added dedicated AWS / EKS support to KubeShark.

Mini recap:

KubeShark is my Kubernetes skill for Claude Code and Codex.

It helps AI agents generate, review, and refactor Kubernetes manifests without falling into the usual LLM traps: missing security contexts, deprecated API versions, broken selectors, wildcard RBAC, unsafe probes, missing resource requests, and rollout configs that look okay but fail under real traffic.

The important part is that KubeShark is failure-mode-first. It does not just tell the model “write good Kubernetes”. It forces the model to reason about what can go wrong before it generates YAML, and then return validation and rollback guidance as part of the answer.

That matters a lot with Kubernetes, because many bad manifests are accepted by the API server and only fail later at runtime.

Repo: https://github.com/LukasNiessen/kubernetes-skill

---

Now what’s new:

KubeShark now has special dedicated AWS / EKS support.

When the task involves EKS, AWS, IRSA, EKS Pod Identity, AWS Load Balancer Controller, EBS/EFS CSI, AWS VPC CNI, or Karpenter, KubeShark switches into EKS-aware guidance.

That matters because EKS is “just Kubernetes” until identity, load balancing, storage, pod networking, and node provisioning enter the picture.

Common LLM mistakes include:

• putting AWS access keys into Kubernetes Secrets
• mixing IRSA and EKS Pod Identity assumptions
• using nginx annotations with AWS Load Balancer Controller
• treating EBS like ReadWriteMany storage
• recommending Karpenter while omitting resource requests
• assuming NetworkPolicy works without checking the CNI/policy engine

Example guidance KubeShark now keeps in mind:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: app
  namespace: payments
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::123456789012:role/payments-app

It also knows that EBS is usually RWO and zone-sensitive, EFS is the RWX option, and Karpenter depends heavily on good workload requests.

So instead of generic Kubernetes advice, you get EKS-aware manifest generation and review.

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

A few of you pointed out two very practical gaps for real Python codebases:
external dependencies, and type-only imports. So to your request I’ve added both.

------

First a mini recap of what ArchUnitPython does:

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

In other words: ArchUnitPython 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/ArchUnitPython

------

Now what’s new

1. External Dependency Rules

Before, ArchUnitPython could already enforce internal dependency rules like:

“presentation must not depend on database” or “services must not import api”

Now it can also enforce rules about imports to modules outside your project, for example:

• domain code must not import requests
• core logic must not import sqlalchemy
• only certain layers may use pandas, boto3, etc.

So you can now guard not just folder-to-folder boundaries, but also framework / SDK usage boundaries.

Example:

rule = (
    project_files("src/")
    .in_folder("**/domain/**")
    .should_not()
    .depend_on_external_modules()
    .matching("requests")
)
assert_passes(rule)

This is especially useful in layered or hexagonal architectures where the real problem is often not “wrong local file import”, but “core code now directly depends on infrastructure/framework code”.

2. TYPE_CHECKING-aware dependency analysis

Python has a common pattern for type-only imports:

from typing import TYPE_CHECKING

if TYPE_CHECKING:
    from my_app.models import User

Those imports are used for static typing, but they are not real runtime coupling in the same way normal imports are.

Previously, architecture analysis would still count them as ordinary dependencies.
Now you can choose to ignore them when checking architecture rules.

Example:

assert_passes(
    rule,
    CheckOptions(ignore_type_checking_imports=True),
)

This matters because modern Python codebases use type hints heavily, and otherwise architecture checks can become noisy or overly strict for relationships that only exist for typing.

------

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