Is there an existing issue for this?

• I have searched the existing issues

Current behavior

With the release of v2.0.0 few dependencies were removed from the project such as inversify utils, chalk and winston. Also, the the express server definitions were moved to the adapter-express repo causing the templates to be updated in favor of this change

Steps to reproduce

expressots new
expressots generate

Both commands are not scaffolding the correct templates

Expected behavior

Generating the templates with the new dependencies

Package version

2.0.0

Which project template was used?

• opinionated
• non-opinionated

Node.js version

18.11.0

In which operating systems have you tested?

• macOS
• Windows
• Linux

Which Package Managers have you tested?

• NPM
• YARN
• PNPM

Other

No response

Is there an existing proposal similar to this?

• I have searched the existing proposals

What are you proposing?

My proposal is to create a command in the CLI to generate the basic Scaffold for Repositories.

Is there any specific group of users that will benefit from this?

There is no specific group for this improvement, but many would benefit, as generating the file becomes a repetitive task, so having a scaffold to automatically generate it reduces repetition.

What problems are you trying to solve?

With this task we can reduce repetitive tasks.

Do you have any references or examples that can illustrate your idea?

N/A

What type of idea is this?

Improvement of existing idea: Similar idea exists but this is an improvement

Description

The goal of this task is to incorporate the ntl package into the CLI component of our system. This integration should allow users to view and run tasks defined in the package.json scripts section directly from the CLI, enhancing the development experience by providing a streamlined way to manage and execute Node tasks.
As well as to consider adding the current expressots CLI commands to be interactive in the same way as the scripts in the package.json

Goals

Enhanced Usability: Streamline the developer's workflow by providing an interactive task runner interface within the CLI.
Simplicity: Ensure the command interface is intuitive, requiring minimal input to access and run tasks.

Requirements

Package Integration:

• Incorporate the ntl package into the CLI tooling setup.
• Verify compatibility with the current CLI and Node.js project setup.

Interactive List Display:

• Implement an interactive command interface that displays available tasks from package.json.
• Include filtering and search capabilities for large lists of scripts.

Execution of Tasks:

• Allow users to execute tasks by selecting from the interactive list without manually typing the full command.
• Provide feedback on task execution status and output within the CLI.

Error Handling:

• Implement robust error handling to provide clear messages for failed tasks or execution errors.
• Ensure the CLI remains stable and recovers gracefully from any task failures.

Documentation and Help:

• Update the CLI help documentation to include the new ntl command usage and features.
• Provide examples of common task interactions and troubleshooting tips.

Testing:

• Create a suite of automated tests to verify that the ntl integration works as expected across various scenarios.
• Include tests for command discovery, interaction, execution, and error handling.

Deliverables

• A working implementation of ntl within the CLI that interacts with the project’s package.json scripts.
• Documentation for the ntl command, updated help commands, and usage guides.
• A comprehensive test suite that ensures the reliability and stability of the ntl integration.
• This task will enhance the developer tooling by streamlining the interaction with Node.js tasks, making the process of managing and running scripts more efficient and user-friendly.

Is there an existing issue for this?

• I have searched the existing issues

Current behavior

When generating a new controller with:

expressots g controller <path>

It creates the controller normally but it adds a broken import to the module

Steps to reproduce

1. expressots g controller <path>
2. checkout the added import on the respective module the controller was added to.

Expected behavior

When generating a new controller it should be added a "./" preventing this bug to happen.

Package version

1.3.1

Node.js version

18.14.0

In which operating systems have you tested?

• macOS
• Windows
• Linux

Other

No response

Proposal:

I propose adding support for the Bun CLI (bunx) in ExpressoTS CLI. Bunx is a tool that offers improved speed and efficiency when running locally installed packages. By adding bunx support, we can enhance the developer experience for ExpressoTS users and make package execution faster.

Benefits:

Faster Execution: Bunx is faster than npx for locally installed packages. This enhancement will lead to significantly faster package execution times for ExpressoTS users.

Efficient Package Management: Bunx checks for locally installed packages first and falls back to installing from npm if needed. This ensures that users have access to the latest package versions.

Improved Developer Experience: ExpressoTS users will benefit from a smoother and more efficient CLI experience, making it easier to work with the framework.

Implementation Details:

To add bunx support to the ExpressoTS CLI, we will need to:

Modify the CLI to recognize and use the bunx command.
Ensure that bunx respects and executes packages as expected.
Test the integration thoroughly to ensure compatibility and performance improvements.

Is there an existing proposal similar to this?

• I have searched the existing proposals

What are you proposing?

To create middleware scaffold

expressots g m <<middleware-name>>

Custom Middleware

class CustomMiddleware extends ExpressoMiddleware {
    private isOn: boolean;

    constructor(isOn: boolean) {
        super();
        this.isOn = isOn;
    }

    use(req: Request, res: Response, next: NextFunction): void | Promise<void> {
        // Do something
        if (this.isOn) {
            next();
        } else {
            res.status(403).send("Forbidden");
        }
    }
}

Is there any specific group of users that will benefit from this?

All framework users

What problems are you trying to solve?

Scaffolding another resource of the framework, custom ExpressoMiddleware

Do you have any references or examples that can illustrate your idea?

class CustomMiddleware extends ExpressoMiddleware {
    private isOn: boolean;

    constructor(isOn: boolean) {
        super();
        this.isOn = isOn;
    }

    use(req: Request, res: Response, next: NextFunction): void | Promise<void> {
        // Do something
        if (this.isOn) {
            next();
        } else {
            res.status(403).send("Forbidden");
        }
    }
}

Generate the new CLI Command:

expressots g m <<middleware-path>>/<<middleware-name>>

To scaffold the code below:

import { ExpressoMiddleware } from "@expressots/core";
import { NextFunction, Request, Response } from "express";
import { provide } from "inversify-binding-decorators";

@provide(AuthMiddleware)
export class AuthMiddleware extends ExpressoMiddleware {
    use(req: Request, res: Response, next: NextFunction): void | Promise<void> {
        throw new Error("Method not implemented.");
    }
}

Folder structure:

Every middleware needs to be created inside of the provider/middleware folder

Case 1: [provider]/[middleware]/<> :: File -> your-middleware-name.<>.ts
Case 2: [provider]/[middleware]/<>/ :: File -> file is the name of the folder

What type of idea is this?

Improvement of existing idea: Similar idea exists but this is an improvement

Description

Add unit tests in all modules.

Current Modules:

• application: app-container, app-factory
• common: color-service, package-resolver, project-config
• console: console
• container-module
• controller: base-controller
• decorator: scope-binding
• error: app-error, error-handler-middleware, report, status-code
• middleware: middleware-resolver, middleware-service
• provider: provider-manager, db-in-memory, dto-validator, env-validator, logger
• render

Suggested Pattern

• Inside of every module, add all unit tests in a folder called __tests__.
• Unit test file names should have the suffix .spec

Requirements

• all features must have tests;
• code coverage must pass.

Description

Automate the renaming of .env.example to .env as part of the project setup process using the ExpressoTS CLI. This step ensures that new projects have a ready-to-use environment configuration file.

Requirements

• Detect the existence of an .env.example file in the project directory.
• Rename .env.example to .env automatically during the project creation phase.
• Ensure the renamed .env file retains the contents and format of the original .env.example.
• Confirm that no .env file already exists before renaming to avoid overwriting.
• Provide feedback to the user upon successful renaming or report any errors encountered.
• Incorporate this renaming feature into the existing CLI workflow without disrupting other setup processes.

Steps required

CLI Specification

First we will need to create a CLI specification, that means, every use case for the CLI utility, i.e.:

expressots-cli --help
xts --help

More than one name perhaps.

Creating a new project?

xts new project
xts import project --url=https://github.com/expressots/expressots-templates/tree/-/main/example-crud

Creating a new so called resource that would be the whole package os useCases, repository, entity.

xts new resource
   -> name
   -> generate tests?

Singular creations of resources, for instance a new useCase

xts new use-case book/loan # a use case that was not default generated

Tools

The CLI probably should be created using TypeScript for the sake of the environment of the affected users (expresso is a JavaScript framework, therefore we suppose that they have a JavaScript environment set, although languages like Go and Rust are better to create a CLI). <--- Discussion needed.

Packaging

Probably in a separate package called expresso-ts-cli, expressots-cli, @expressots/cli, @expresso-ts/cli or any other permutations.

Is there an existing issue for this?

• I have searched the existing issues

Current behavior

No module scaffold

Steps to reproduce

N/A

Expected behavior

Ability to scaffold module

Package version

N/A

Node.js version

N/A

In which operating systems have you tested?

• macOS
• Windows
• Linux

Other

No response

Is there an existing issue for this?

• I have searched the existing issues

Current behavior

Module is scaffolded in non opinionated template when the user generates a controller. This behavior should only be applied to services or controllers in the opinionated template

In the non opinionated template module should be scaffolded individually

Steps to reproduce

In the non opinionated template:

expressots g c controller/user

It generates module as well

Expected behavior

Controller scaffolld should just generate the controller

Package version

1.4.0

Node.js version

18.11.0

In which operating systems have you tested?

• macOS
• Windows
• Linux

Other

No response

Description

Add unit tests in all modules.

Current Modules:

• application: app-container, app-factory
• common: color-service, package-resolver, project-config
• console: console
• container-module
• controller: base-controller
• decorator: scope-binding
• error: app-error, error-handler-middleware, report, status-code
• middleware: middleware-resolver, middleware-service
• provider: provider-manager, db-in-memory, dto-validator, env-validator, logger
• render

Suggested Pattern

• Inside of every module, add all unit tests in a folder called __tests__.
• Unit test file names should have the suffix .spec

Requirements

• all features must have tests;
• code coverage must pass.

Create container in order to test in Windows, Linux & MacOS

• TODO: describe issue

Introduction

The existing CLI commands for starting the application and running in development mode could be simplified and optimized. Currently, the following commands are used:

• Start: node -r dotenv/config -r ./dist/register-path.js ./dist/src/main.js
• Development: tsnd -r dotenv/config -r tsconfig-paths/register ./src/main.ts

The proposal is to replace these with two simple commands, start and dev, and change the underlying package from ts-node-dev to tsx.

Proposed Changes

1. Replace Start Command: Introduce a start command to replace the current complex command.
2. Replace Development Command: Introduce a dev command for development, replacing the existing command.
3. Move from ts-node-dev to tsx: As ts-node-dev has not been actively maintained and tsx (https://github.com/esbuild-kit/tsx) has been more broadly used, it is suggested to migrate to tsx, which may provide better performance and compatibility.

Implementation Details

start Command:

The start command can replace the current command for running the application.

expressots start

dev Command:

The dev command can replace the current command for running the development server.

expressots dev

Use tsx:

Move from ts-node-dev to tsx

Overview

I'm proposing to migrate from ts-node-dev to tsx (https://github.com/esbuild-kit/tsx) for running TypeScript files. This change is driven by the following critical factors:

Active Maintenance

• ts-node-dev: The ts-node-dev package has not been actively maintained, with the latest updates showing a lack of consistent development. This poses a risk of running into unsupported issues or bugs that might not be addressed promptly.
• tsx: In contrast, tsx is an actively maintained package with regular updates, ensuring that it keeps up with the latest TypeScript features and best practices. This active maintenance promotes stability and support for future enhancements.

Performance

• Faster Compilation: tsx uses esbuild, known for its remarkable compilation speed. This speed can make the development process more efficient, particularly in large codebases.
• Reduced Startup Time: tsx optimizes the startup time, enabling quicker iterations during development. This can save valuable time for developers and streamline the workflow.

Compatibility

• Latest TypeScript Features: tsx supports the latest TypeScript features, ensuring compatibility with modern development practices and tools.
• Flexibility with Configuration: tsx provides a flexible configuration system, allowing customization and fine-tuning to fit the specific needs of the project.

Community Adoption

• Wider Usage: tsx has seen more extensive adoption within the community, reflecting a positive reception and trust in the package.
• Contributions: Being a more popular package, tsx benefits from community contributions, resulting in a more refined and robust solution.

Conclusion

The migration from ts-node-dev to tsx offers substantial benefits, including enhanced performance, active maintenance, and compatibility with modern development practices. Aligning with a package that enjoys broader community support will contribute to the project's long-term success and maintainability. Therefore, transitioning to tsx is a strategic move that we believe will positively impact the development experience in ExpressoTS.

Benefits

• Simplicity: Simplifies the commands to start and develop the project.
• Maintainability: Utilizes a well-maintained and widely-used package (tsx) over ts-node-dev.
• Performance: Potentially provides improved speed with tsx.

Conclusion

These changes aim to enhance the CLI experience by providing more straightforward commands and migrating to a more efficient and actively maintained package. Feedback are welcome for this proposed update.

Is there an existing issue for this?

• I have searched the existing issues

Current behavior

Installing the package in the yarn global works but executing any command I get this issue:
-bash: /usr/bin/expressots: No such file or directory

OS: Ubuntu 20.04 LTS

Steps to reproduce

1. Install the package on yarn globally -> yarn global add @expressots/cli
2. Execute any command -> expressots new or expressots --version

Expected behavior

The expected behavior should be prompting the user to create the project

Package version

1.1.1

Node.js version

18.14.2

In which operating systems have you tested?

• macOS
• Windows
• Linux

Other

No response

Is there an existing issue for this?

• I have searched the existing issues

Current behavior

Currently CLI is providing it's first provider which as @expressots/prisma or prisma provider. Prisma provider is added using the CLI command:

expressots add prisma

We need to add a command to remove the provider and undo all it's installation changes. Example:

expressots remove prisma

During the installation prisma does:

• Install prisma client
• Install prisma
• Install @expressots/prisma
• Install driver
• Install repository pattern
• Create a prisma folder
• Add prisma folder location to the package.sjon
• Add prisma provider configuration in the expressots.config.ts
• Add prisma command in package.json to generate prisma models

Steps to reproduce

expressots add prisma

Expected behavior

Remove all components below:

• Install prisma client
• Install prisma
• Install @expressots/prisma
• Install driver
• Install repository pattern
• Create a prisma folder
• Add prisma folder location to the package.sjon
• Add prisma provider configuration in the expressots.config.ts
• Add prisma command in package.json to generate prisma models

Package version

@expressots/cli 1.5.0

Node.js version

18

In which operating systems have you tested?

• macOS
• Windows
• Linux

Other

No response

Description

The objective of this task is to create a scaffold for external providers in the form of an NPM package that can be easily integrated into the ExpressoTS framework. Developers should be able to implement the IProvider interface from ExpressoTS Core and register their custom class within the application’s provider manager. The scaffold must support the definition of class scope binding (such as singleton, request, or scope) to align with the plugin pattern of ExpressoTS.

The idea is to clone a specific repo that contains a project with a standard configuration for creating new NPM packages with the supporting types to be a ExpressoTS provider.

Command idea: expressots add <provider-name> [external] [library-version] [provider-version]

Goals

• Ease of Implementation: Ensure that the scaffold simplifies the process of creating and integrating new providers into ExpressoTS.
• Compliance with ExpressoTS Plugin Pattern: The scaffold should be fully compatible with the plugin system and enforce the implementation of the IProvider interface.
• Scope Binding Support: Allow developers to define their provider’s lifecycle scope, such as singleton, request, or scoped.

Deliverables

• A complete scaffold for creating external providers as NPM packages, ready for use by developers.
• Detailed documentation included within the scaffold for guiding developers through the creation and integration process.
• A testing suite that can be run to validate the functionality of the scaffold and the created provider.

This task will facilitate the growth of the ExpressoTS ecosystem by enabling developers to contribute custom providers that can be shared and reused within the community, furthering the framework’s extensibility and functionality.

Hello everyone, I would like to suggest an improvement that can be interesting for our project: the use of the transpiler SWC, which is a tool written in rust and that has been standing out in the market, being adopted by Next.js to optimize the developer experience and the performance of build, making it much faster.

According to the official website of SWC, it is 20x faster than Babel on a single thread and 70x faster on four cores. In addition, it supports several features of modern JavaScript, such as arrow functions, optional chaining, TypeScript and more.

The changes that I propose are the following:

• Add a command option, for example: --experimental, --use-swc, so that the template uses the build with SWC
• Change or create a template so that the npm scripts of the package.json use the experimental build

This change in the package.json already depends on the solution of issue #15, which is in progress.

Thank you for your attention!