DEV Community: Signor_P

Nexcord@0.0.3

Signor_P — Sun, 19 Jul 2026 15:33:32 +0000

Nexcord 0.0.3 — Release Notes

🔄 Circular Dependency Resolution: Container Layer Added on Top of Proxy

The Lazy Proxy mechanism from 0.0.2 hasn't been replaced — a new container layer now sits underneath it, controlling the dependency resolution process. Circular dependency detection and instance bookkeeping are now handled centrally through DependencyContainer and ServiceContainer, while the Proxy remains active at runtime for safe method-call access.

Why this was needed: in the previous version, circular resolution logic was scattered and it was hard to trace when and in what order service instances were being created. With 0.0.3:

DependencyContainer — holds a class's declared dependencies (including those marked with @Inject()) and resolves them recursively via addDeps().
ServiceContainer — holds each service's singleton instance, its circular flag, and its resolution state. Instance creation is now fully managed through addInstanceDeps().

When a circular dependency is detected, the flow now works as follows: DependencyContainer first checks whether the relevant service is already registered in ServiceContainer; if it is and carries the circular flag, the service is re-flagged as circular: false and its instance is rebuilt to break the cycle. This means work that was previously left entirely to the Proxy is now tracked and observable at the container level.

// Behavior stays the same from the developer's side — nothing changes here
@Service()
export class AService {
    constructor(@Inject(() => BService) private readonly bService: InjectType<BService>) { }

    a() {
        this.bService.b() // now resolved more reliably thanks to the container layer
    }
}

Note: this release also fixes a logic bug in ServiceContainer.get() where the slient (silent mode) flag was inverted — silent mode no longer throws, allowing the circular resolution flow to correctly fall through to undefined as intended.

🧱 New Architecture: Isolated Per-Feature Containers

The biggest structural change in 0.0.3. Every decorator — @Service(), @Guard(), @SlashCommand(), @Listener() — now has its own dedicated container class. In the previous version all of these class types were loosely managed through a single shared structure; in 0.0.3 each feature lives in its own container and is fully isolated from the others.

What this means in practice:

How a @Guard() class is registered, which routes it owns, and how it's instantiated is now entirely the responsibility of its own container — with no overlap with the @Service() or @SlashCommand() containers.
Each container has its own add() / get() contract, but all of them ultimately hand off to ServiceContainer for dependency injection. In other words, every feature gains its "value" through its own container, while instance management and DI resolution remain centralized.
Thanks to this isolation, a change in one container (e.g. an update to Guard route-matching logic) can no longer leak into the behavior of other containers — something that was possible in the previous version.

In short: the registration/definition layer is now split per feature, while the instantiation and dependency resolution layer remains centralized.

🛡️ Type-Safe Event Handler Parameters: `DcEvents<T>` Re-enabled

This feature isn't new — it existed at the core level before but had been disabled. 0.0.3 both updates it and turns it back on.

@On(eventName) and @Once(eventName) decorators now check, at compile time, whether your method's parameters match the correct type for the given event name. The DcEvents<'eventName'> helper type automatically resolves the correct parameter signature for the discord.js event in question.

@On('clientReady')
async ready(...[client]: DcEvents<'clientReady'>) {
    this.loggerService.log(`${client.user?.username} active`)
}

If you mistakenly annotate the client parameter here as string, TypeScript will fail at compile time — because DcEvents<'clientReady'> is bound to the real parameter signature ([Client<true>]) of the 'clientReady' event on the discord.js side, and the decorator enforces it.

Something to keep in mind: this check only works based on the literal event name string you pass to @On / @Once — the more specific the eventName, the more precise the type inference. With generic or dynamic event names (@On(someVariable)), this type narrowing won't kick in.

📋 Summary Table

Change	Scope	Impact
Container-based circular dependency resolution	Core (`DependencyContainer`, `ServiceContainer`)	Added on top of the Proxy mechanism, not a replacement
`slient` flag logic bug fix	`ServiceContainer.get()`	Improves reliability of the circular resolution flow
Isolated per-feature container architecture	All decorators (`@Service`, `@Guard`, `@SlashCommand`, `@Listener`)	Registration/definition layer split apart, DI stays centralized
`DcEvents<T>` type checking	`@On` / `@Once` decorators	Existed before, was disabled — updated and re-enabled in this release

I Built a Framework for discord.js (Meet Nexcord)

Signor_P — Sat, 11 Jul 2026 16:07:17 +0000

Building Discord Bots Shouldn't Feel Like Wiring Everything Together — Meet Nexcord

If you've ever built a Discord bot with discord.js, you've probably ended up writing code that looks something like this:

Register every command manually.
Register every event manually.
Create service instances yourself.
Pass dependencies through constructors.
Keep import lists up to date as the project grows.

None of these tasks are particularly difficult.

But after you've done them dozens of times, they start feeling more like maintenance than development.

After working on several Discord projects, I found myself wanting something closer to the experience of frameworks like NestJS or Angular, while still keeping everything I like about discord.js—its flexibility, performance, and ecosystem.

That's how Nexcord started.

What is Nexcord?

Nexcord is a decorator-driven, dependency-injection-powered framework built on top of discord.js.

Rather than spending time wiring your application together, you simply describe what each class is responsible for.

@Service()
export class GreetingService {
  greet(name: string) {
    return `Welcome ${name}!`;
  }
}

@Listener()
export class MemberListener {
  constructor(private readonly greeting: GreetingService) {}

  @On('guildMemberAdd')
  async execute(member: GuildMember) {
    await member.send(
      this.greeting.greet(member.user.username)
    );
  }
}

There's no need to manually create services.

No event registration to keep track of.

No growing bootstrap file that slowly turns into hundreds of lines.

Nexcord discovers your classes automatically, builds the dependency graph, and wires everything together for you.

Dependency Injection without the Boilerplate

Dependency Injection isn't a new idea.

What interested me was bringing the same experience to Discord bot development.

Every class decorated with one of Nexcord's decorators automatically becomes part of the dependency injection container.

@Service()
class QuoteService {}

@SlashCommand(...)
class QuoteCommand {
    constructor(
        private readonly quotes: QuoteService
    ) {}
}

If QuoteService depends on another service...

...and that service depends on another...

...Nexcord resolves the entire dependency graph automatically.

Each service is instantiated only once and shared across the application, so you don't have to think about lifecycle management.

Convention over Configuration

One thing that always bothered me in larger projects was maintaining registration files.

Every new command or listener meant adding another import somewhere.

Eventually those files became longer than the actual feature I was implementing.

Nexcord takes a different approach.

src/
 ├── commands/
 ├── events/
 ├── configs/
 ├── common/

When the application starts, these folders are scanned automatically.

Add a new command.

Run the bot.

That's it.

No extra registration step.

Guards for More Than Commands

Most Discord frameworks offer middleware, but it's usually tied to slash commands.

I wanted something that worked everywhere.

That's why Nexcord introduces Route Forwarding Guards.

A guard can target:

individual listeners
commands
groups of handlers
wildcard patterns
regular expressions
prefixes and suffixes

For example:

@Guard(
    { MemberListener },
    "checkCooldown->MemberListener::onMessage"
)

If the guard returns false, execution stops before the listener ever runs.

The same mechanism works consistently for commands and events, so you don't need different middleware systems depending on what you're handling.

Shared Configuration that Understands Dependency Injection

Configuration is often more than static strings.

Sometimes generating a configuration value requires access to another service.

That's the reason I built @nexcord/config.

Instead of writing something like this during startup:

const prefix = prefixService.get();

you register the configuration once.

registerConfig(
    "messages.welcome",
    (prefix: PrefixService) =>
        `Type ${prefix.get()}help`,
    PrefixService
);

Nexcord automatically resolves PrefixService.

The value is computed once and becomes available everywhere through ConfigService.

For values that require the Discord client to already be connected, there's also registerConfigWait().

JSX for Discord Components

Anyone who's built more complex Discord UIs knows that component builders can become fairly verbose.

Buttons.

Embeds.

Select menus.

Modals.

Components V2.

All of them involve long builder chains that can quickly become difficult to read.

Nexcord includes @nexcord/tsx, a JSX runtime designed specifically for Discord components.

<button
    id="confirm"
    label="Confirm"
    style="success"
    action={ConfirmAction}
/>

This compiles directly into the appropriate discord.js builders.

There's no virtual DOM.

No rendering engine.

Just a cleaner, more expressive syntax for creating Discord components.

Built Around an Ecosystem

Nexcord is currently made up of three packages.

@nexcord/core — decorators, dependency injection, automatic discovery, guards, and the framework runtime.
@nexcord/config — dependency-injection-aware shared configuration.
@nexcord/tsx — a JSX runtime for Discord components.

Each package can be used independently.

Together, they provide a more structured and enjoyable development experience.

Why I Built It

Nexcord wasn't created because Discord needed another library.

discord.js already does an excellent job.

The motivation was different.

I wanted to spend less time wiring projects together and more time building actual features.

Less repetitive setup.

Cleaner architecture.

Automatic discovery.

Dependency injection.

Better organization as projects grow.

Nexcord doesn't try to replace discord.js.

It simply aims to provide a higher-level development experience on top of it.

Current Status

Nexcord is currently in beta.

The core architecture is already in place, but there are still APIs I'm refining before the 1.0 release.

This stage is where feedback matters the most.

Many of the decisions that will shape the stable release are still open to improvement, so hearing how other developers approach Discord bot development is incredibly valuable.

If you're interested in building larger Discord bots with a more structured architecture, I'd genuinely love to hear your thoughts.

Thanks for reading.

Just one question, one answer.

Signor_P — Mon, 25 May 2026 04:35:48 +0000

When you start a project, what's the maximum and minimum time it takes you to get the setup/configuration ready? In other words, how long does it take before you start writing the features or code that are the reason you created the project? I'd love to hear your thoughts in the comments! 🐾🤍

Next-gen PHP Framework Lynx

Signor_P — Wed, 20 May 2026 16:17:20 +0000

NestJS + PHP = Lynx

Greetings, how are you? I hope your code and errors are plentiful. I'm back here after a long time. Let me briefly introduce myself. I'm a self-employed developer/entrepreneur who has been designing backend and system architecture with TS for 3-4 years. Everyone online knows me as Signor P. I'm here to announce that I've released my Lynx framework as open source, as I mentioned to you in the past. Lynx started as a hobby project, and then I asked myself, why not share it with other developers and develop it together? 😅. Briefly, Lynx is a backend framework written in pure PHP with a NestJS architecture and syntax. It's a framework with a small CLI tool written in Rust and a database system with a small TypeORM syntax. Developers who want more technical details can check the Github repositories. So why did I write Lynx... I sometimes need to write PHP or want to write PHP. But huge frameworks like Laravel tire me out. Minimal and spacious frameworks are rare in the PHP world. As a TS developer myself, I thought, why not port a TS framework to PHP? And I decided that NestJS was the most suitable framework for this. I use Lynx myself in some hobby projects and prototypes. When I needed to write a manager for database operations, I thought, why not use the TypeORM syntax that I always use and that is compatible with NestJS? And although not exactly the same, I added a database layer in a similar TypeORM style. Entities, Repository usage, etc... Currently, Lynx works for small projects and some medium-sized projects. However, it's worth mentioning that I am not a security expert or professional software engineer. Yes, I have a few successful projects that I haven't published yet, but I should point out that I'm not that good at PHP. Let's take a brief look at the project architecture.

📁 your-project-root
├── 📁 App                         # 🐾 LYNX CORE ENGINE (Zero dependencies, pure PHP)
│   ├── 📁 Builder                 # Fluent factories (e.g. ExceptionBuilder)
│   ├── 📁 Cache                   # Temporary runtime caching & logger.json storage
│   ├── 📁 Config                  # Framework system configuration
│   ├── 📁 Core                    # Kernel, Request, Response, Router, Autoloader, & Repositories
│   ├── 📁 Decorators              # Core attributes (Module, Controller, Column, GET/POST, Inject, etc.)
│   ├── 📁 Exception               # Built-in HTTP exceptions (BadRequest, NotFound, etc.)
│   ├── 📁 Helper                  # Console logs, secure encryption, tokenizers, & .env loaders
│   ├── 📁 Interface               # LogLevels, Middleware, & ExceptionFilter contracts
│   └── 📁 Templates               # Default engine templates (e.g. default 404 page)
├── 📁 Src                         # 🏗️ APPLICATION DOMAIN CODE (Write your code here)
│   ├── 📁 views                   # HTML template 'welcome' views & custom 404s
│   ├── 📄 AppController.php       # Root application routes controller
│   ├── 📄 AppMiddleware.php       # Root application middleware pipeline
│   └── 📄 AppModule.php            # Root AppModule configuration (orchestrates sub-modules)
├── 📄 .env                        # Environment Configuration (DB credentials, status, etc.)
├── 📄 .htaccess                   # Apache URL-rewriting configuration
└── 📄 index.php                   # Core application entrypoint (boots LynxApplication)

<?php

// index.php

require_once './App/Core/AutoLoader.php';

use App\Core\LynxApplication;
use Src\AppModule;

global $app;
$app = new LynxApplication(AppModule::class);
$app->run();


// Src/AppModule.php

<?php

namespace Src;

use App\Decorators\Module;
use Src\AppController;

#[Module([
    'controllers' => [AppController::class]
])]
class AppModule {}

<?php

// Src/AppController.php

namespace Src;

use App\Core\Request;
use App\Core\Response;
use App\Decorators\Controller;
use App\Decorators\Get;
use App\Decorators\Post;
use App\Decorators\Middleware;

#[Controller()]
#[Middleware([AppMiddleware::class])]
class AppController
{
    #[Get('/')]
    public function get(Request $req, Response $res): void
    {
        $res->render('welcome', ['name' => 'Lynx']);
    }

    #[Post('/')]
    public function logout(Request $req, Response $res): void
    {
        $res->json([
            "framework" => "Lynx"
        ]);
    }
}

<?php

// Src/AppMiddleware.php

namespace Src;

use App\Core\Request;
use App\Core\Response;
use App\Helper\Console;
use App\Interface\Middleware;

class AppMiddleware implements Middleware
{
    public function use(Request $req, Response $res, mixed $next): void
    {
        Console::log('info', 'Run App Middleware');
        $res->setHeader('X-Powered-By', 'Zexson Team');
        $next($req, $res);
    }
}

As you can see, you can develop PHP backend applications in the style of NestJS. I enjoy using Lynx and I like it very much. I hope this open-source project hasn't wasted your time. That's all for now. The necessary links are below. I eagerly await your feedback 🐾

🦄

Lynx
Lynx CLI
Let's chat and develop our projects like Lynx together.
Discord

Why would deleted files remain in the dist?

Signor_P — Thu, 10 Jul 2025 14:40:59 +0000

When working with TypeScript, you might have noticed something odd:

You delete a .ts file — but its compiled .js and .d.ts files are still hanging around in your dist/ folder... 🤨

If you're like me, your first instinct is:

“Wait... shouldn't tsc take care of this automatically?”

Unfortunately, no.

🤔 Why This Happens

The TypeScript compiler (tsc) compiles .ts files to .js, .d.ts, and .map.js, but it does not clean up old files. If you delete a source file, the compiled version stays in your output directory.

That leftover file might:

Still get imported
Cause your app to crash unexpectedly
Create hard-to-track bugs
Waste space, especially in limited environments

🛠️ The Fix: `tsc-clear`

To fix this, I built tsc-clear:
A lightweight Rust-powered CLI that automatically cleans up your dist/ folder by removing any compiled files (.js, .d.ts, .map.js) that no longer have a corresponding .ts file in your project.

✨ Key Features

🧹 Auto-cleans stale files after compilation
⚡ Fast — written in Rust for high performance
⚙️ No configuration needed — reads tsconfig.json to detect your outDir
🪟 Windows only for now (cross-platform support planned)

📦 Install It Globally

npm install -g tsc-clear

🚀 Example Usage

Update your package.json scripts like this:

{
  "scripts": {
    "start": "tsc && tsc-clear src && node dist/index.js"
  }
}

tsc-clear runs after tsc and before node, ensuring that your output directory is clean and safe.

🧠 Why I Built It

I was working on a project where I kept removing and renaming files — and everything looked fine... until I ran the app and hit an error caused by a file I had deleted days ago 😵

The old .js file was still sitting in dist/, silently breaking everything.

After searching for a solution and finding nothing lightweight, native, and easy to use — I decided to build tsc-clear for myself.

Now I’m sharing it with you. ✨

✅ TL;DR

TypeScript doesn't clean up dist/
Old files can break your app or cause unexpected behavior
tsc-clear solves this in one command

🔗 Links

GitHub Package Repo: github.com/SignorMassimo/tsc-clear
GitHub Rust Repo: github.com/SignorMassimo/tsc-clear-rust
npm: npmjs.com/tsc-clear

Thanks for reading!
Let me know if this tool helped you — or drop a star ⭐ on GitHub if you like it!
Happy coding! 🧼💻

My new ORM NPM package MiniORM

Signor_P — Fri, 23 May 2025 19:32:47 +0000

Introducing MiniOrm – a lightweight and intuitive ORM built with TypeScript.
It supports MySQL, PostgreSQL, and SQLite out of the box, and offers a clean, fluent API for building queries without sacrificing performance or control.

✨ Features:

QueryBuilder with strong typing
Support for raw SQL when needed
Simple and, or conditions
Class-based fluent API
Fully open-source and framework-agnostic

Whether you're building a small side project or a full-scale backend, MiniOrm offers the right balance between simplicity and power.

📦 NPM: https://www.npmjs.com/package/miniorm-ts
📚 Docs: https://zexson-dev.vercel.app/miniorm
💻 GitHub: https://github.com/SignorMassimo/miniorm
🎥 Video: https://www.youtube.com/watch?v=RIC5cRqNtY8

Lynx Framework for Sale🙂🐾

Signor_P — Tue, 06 May 2025 11:11:32 +0000

Old Content:
Hello everyone,

I have put the Lynx project on hold because I am currently busy with another project. Although Lynx is a solid framework, I cannot develop two projects at the same time by myself.

Since I no longer have time to continue the development of Lynx, I am thinking of offering it for sale. If you represent a company, I would be happy to join your Lynx team if needed. Lynx already has a solid foundation with an ORM and a CLI. The CLI is written in Rust and the ORM is natively integrated into Lynx.

I will share code samples related to Lynx with serious buyers.

Contact me:

Instagram: Signor P
Discord (and other platforms): _signor_p_

New Content:
Now for Sale thank you everyone 🙂

Lynx Prototype Website Released...🐾

Signor_P — Sat, 29 Mar 2025 08:48:00 +0000

Lynx cPanel Prototype is Live!

Hello developers! 🚀 We have officially launched Lynx’s prototype site running smoothly on cPanel. Here’s a quick summary of what’s new in this phase.

CDN System Integrated

For the first time, we are introducing an optional CDN system in Lynx projects! 📡 You will be able to manage your static files effortlessly via a dedicated CDN panel, ensuring better performance. The CLI tool will allow seamless CDN integration with just a few commands.

Lynx in a Real Environment

This prototype demonstrates Lynx’s ability to connect to a real MySQL server and handle sessions and data management flawlessly.

🔹 Runs fully within a cPanel environment

🔹 Includes a simple authentication system

🔹 Features an admin panel with limited data access

We have just started focusing on security, and we are committed to making Lynx as safe as possible. 🔒

Explore the Prototype!

Want to see how Lynx performs on cPanel? Check out our live prototype site:

👉 Lynx Prototype Site
cdn login data...
username: user
password: password

To access other pages. To open an account, you only need to enter a username and password, no other data is taken behind. It is already a prototype and test site.

Stay Connected and Follow Our Progress!

We plan to release Lynx in the coming months, even if it is not completely finished.

We’re continuously working to bring a fresh perspective to PHP development. Lynx is not finished yet, but we’re making big strides! 💡🐾

Lynx in CPanel🦄

Signor_P — Wed, 26 Mar 2025 20:06:55 +0000

Signor_P: First of all, I send my greetings to all of you :).
We’re thrilled to share the latest update on Lynx’s performance on cPanel! Although the MySQL connection functionality has been in place, we recently tested it on cPanel and the system has been fully approved. In addition, we’re just starting to focus on the security aspect, ensuring that every component of Lynx is as safe as possible.

A Brief Overview of the Database System

With Lynx, managing your database has never been easier. Here’s a quick deep note on how it works:

Simple Table Creation: Simply write your table definitions in a PHP file.
Automatic Detection: Whenever your Lynx project performs a database-related operation, Lynx automatically detects it and creates the necessary tables.
Lynx-Specific Features: Enjoy a range of unique features that simplify and streamline your database management directly from your code.

Demo Site Overview

Our upcoming demo site is designed to showcase Lynx’s capabilities:

Simple Auth System: Register an account to access various pages.
Admin Panel: Once logged in, explore a secure admin panel displaying limited, protected data.
Real-World Test: See firsthand what you can achieve with Lynx in a real, tested environment 😄.

Built with Pure PHP

Lynx is crafted using pure PHP, ensuring there are no unnecessary dependencies. We recognize that being built purely in PHP might feel like taking a step back for some modern features, but this design choice is intentional. For those who need advanced dependency management, Lynx can be optionally integrated with tools like Composer, ensuring full compatibility with modern technologies.

Stay connected and follow our journey:

Let’s continue to push the boundaries of PHP development together 🤍🐾

Simple Encryption Solutions with Zexson Toolkit

Signor_P — Fri, 21 Mar 2025 13:04:11 +0000

zexson_toolkit is an npm package you can use for data encryption, token generation, and string manipulation. Below is a quick look at the package's main features and usage examples.

Key Features

Encryption & Decryption: Securely encrypt your data and decrypt it when needed.
Token Generation: Create tokens with customizable length and character sets.
String Comparison: Perform simple text comparisons to ensure data consistency.

Usage Examples

1. Encryption & Decryption

import { encrypt, decrypt } from 'zexson_toolkit';

const data = "secret information";
const encrypted = encrypt(data, { key: 'customKey' });
const decrypted = decrypt(encrypted, { key: 'customKey' });

console.log(decrypted); // "secret information"

2. Token Generation

import { tokenGenerator } from 'zexson_toolkit';

const token = tokenGenerator(16, 'defaultSet');
console.log(token);

Conclusion

zexson_toolkit provides simple and effective solutions for data encryption and token management in your projects. For more details and examples, visit the npm page.

Speaking of our NPM package, we will be releasing our new package for web development very soon 🚀! This package is being developed with the philosophy of your needs (less code, more work), so developers can focus only on your project instead of dealing with complex configurations 🤍. The package will continue to be versioned, adding small features...⭐

Lynx: The Next-Gen PHP Framework

Signor_P — Wed, 19 Mar 2025 06:38:04 +0000

PHP has been a dominant force in web development for years, but it’s time for a fresh perspective. Lynx is here to redefine PHP development, bringing a powerful and modern framework to developers who demand both flexibility and performance.

A New Era for PHP Developers

Lynx is built for developers who want a streamlined, modular, and high-performance PHP experience. It offers a clean architecture, efficient development tools, and an optimized workflow to elevate your projects.

Why Lynx Stands Out

Modular and Scalable Design – Build applications with clean separation and maintainability.
High-Performance Core – Powered by Rust at critical levels for an unmatched developer experience.
Seamless Middleware System – Efficient request handling with full control.
Developer-Friendly CLI – Automate and accelerate your workflow effortlessly.

A New Standard for PHP

Lynx is more than just a framework—it’s a movement towards a more efficient and powerful PHP ecosystem. Stay tuned for its release and join a community that is shaping the future of PHP development.

Signor_P & Zexson Team

"Software should always be easy. When someone starts programming today, they shouldn’t have to spend too much time just learning the technologies needed for web development. This may vary from person to person, but as engineers, we must always minimize this time. Lynx is just the beginning. We hope you like it when it’s released. One of the reasons I created Lynx is because popular but heavier frameworks like Laravel dominate the market. From my experience, they add unnecessary overhead for small to medium-sized projects. Zexson Team will continue developing for you. Instead of spending time learning, configuring, installing packages, or handling system integrations, most of these processes will be handled automatically by the system, allowing you to focus solely on your work. Remember, Zexson Team doesn’t just provide technology—it gives you back a significant part of your time. 😄"

If you want to support us now, you can reach out on Instagram and Discord at _signor_p_.