Coder Social home page Coder Social logo

expressots / expressots Goto Github PK

View Code? Open in Web Editor NEW
1.6K 14.0 41.0 1.7 MB

A Typescript + Node.js lightweight framework for quick building scalable, easy to read and maintain, server-side applications 🐎

Home Page: https://expresso-ts.com/

License: MIT License

TypeScript 95.57% Shell 0.06% JavaScript 4.38%
nodejs clean-architecture microservices typescript typescript-framework expressots hacktoberfest

expressots's Introduction

Codecov NPM Build Contributors Forks Stargazers Issues MIT License LinkedIn


Logo

ExpressoTS Framework

Everything you need to know to build applications with ExpressoTS
Explore the docs »

Let's discuss · Report Bug · Request Feature

Table of Contents
  1. About The Project
  2. Getting Started
  3. Contributing
  4. Support the project
  5. License

About The Project

ExpressoTS is a Typescript + Node.js lightweight framework for quick building scalable, easy to read and maintain, server-side applications 🐎

Getting Started

Contributing

Welcome to the ExpressoTS community, a place bustling with innovative minds just like yours. We're absolutely thrilled to have you here! ExpressoTS is more than just a TypeScript framework; it's a collective effort by developers who are passionate about creating a more efficient, secure, and robust web ecosystem. We firmly believe that the best ideas come from a diversity of perspectives, backgrounds, and skills.

Why Contribute to Documentation?

  • Share Knowledge: If you've figured out something cool, why keep it to yourself?
  • Build Your Portfolio: Contributing to an open-source project like ExpressoTS is a great way to showcase your skills.
  • Join a Network: Get to know a community of like-minded developers.
  • Improve the Product: Help us fill in the gaps, correct errors, or make complex topics easier to understand.

Ready to contribute?

Support the project

ExpressoTS is an independent open source project with ongoing development made possible thanks to your support. If you'd like to help, please consider:

License

Distributed under the MIT License. See LICENSE.txt for more information.

(back to top)

expressots's People

Contributors

abdel-monaam-aouini avatar akhileshjyotishi avatar alphusbr avatar amorim33 avatar antonyz89 avatar caioaugustoo avatar daniel-boll avatar dependabot[bot] avatar devbr-io avatar devsargam avatar eryk-vieira avatar f0ntana avatar hayawata3626 avatar joaoneto avatar juliano-soares avatar lucashfreitas avatar mohanadft avatar renatojdev avatar rsaz avatar shravan20 avatar snyk-bot avatar vitorcaminha avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

expressots's Issues

Comparison with other tools

Is there an existing proposal similar to this?

  • I have searched the existing proposals

What are you proposing?

It would be helpful when choosing a framework like this to compare with the existing ecosystem. It's always a gamble to choose a "new" framework so it helps to lay the ground clearly about how this compares with other existing competition - in this case, frameworks like Nest and Adonis come to mind

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

Anyone performing discovery on which tooling to use

What problems are you trying to solve?

I'm trying to make the pros and cons of this tool more discoverable

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

There are many comparisons of existing frameworks covering things like:

  • Features
  • Benchmarks
  • Integrations
  • Community
  • Etc..

What type of idea is this?

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

Add support to Fastify HTTP server

Description

Integrating Fastify support into your existing application structure, which currently supports primarily to Express, involves several key steps. The goal is to abstract common functionalities between Express and Fastify (or any future web servers we plan to support) so that our core application logic remains agnostic of the underlying web server technology.

Requirements

  • Abstract common interfaces between express and fastify, example: request handler, middleware (plugin), providers, initialization and server configuration
  • Update AppFactory to accomodate any server of type ServerAdapater
  • Middleware compatibility
  • Adapt the App Class
  • Route handling
  • Application lifecycle
  • Inversify decorators and container

Implementing Environment Separation Mechanism in ExpressoTS (.local and .prod)

Description

Create mechanism separating and managing environment-specific configurations across local development, and production (.prod) environments. With recent versions of Node.js enhancing support for .env files, it is now feasible to integrate a native approach to handle environment variables efficiently. This initiative aims to ensure secure, clear, and convenient configuration management that supports the framework's scalability and security needs.

Requirements

  • Outline a clear strategy for structuring .env files and their corresponding environments (.local, .prod).
  • Implement a secure method for storing sensitive configurations, ensuring they are not exposed in version control.
  • Develop a mechanism to automatically detect the current environment and load the corresponding .env file without manual intervention.
  • Ensure compatibility across different operating systems and development environments.
  • Utilize the latest Node.js features for environment variable management to ensure optimal performance and compatibility.

Search on changing the Http Decorators to convert the payloads in the appropriate types

Description

In your TypeScript code, when handling parameters coming from URL paths (like :id in your Express routes), these parameters are always passed as strings, even if they are originally numbers. This is a common behavior in many web frameworks, including those built on Express.js

// Controller
@Get("/:id")
    findOne(@param("id") id: number) {
        return this.userUseCase.findOne(Number(id));
    }

// Use Case
findOne(id: number) {
        return this.db.users.find((user) => user.id === id);
    }

// DB
const users = [
        {
            id: 1,
            name: "Alice Smith",
            email: "[email protected]",
            role: "Admin",
        },
        {
            id: 2,
            name: "Bob Johnson",
            email: "[email protected]",
            role: "Regular",
        }
]

Comparing directly the id from the request without casting to Number will result in undefined behavior as the types are different.

This tasks consists on testing the possibility of inline decorator casting, to improve the clarity and maintainability of your code, consider handling the type conversion within your controller methods or even using middleware to automatically convert parameters.

Integration of Snyk for Vulnerability Detection in ExpressoTS

Description

This issue aims to explore and integrate Snyk for identifying and fixing vulnerabilities in codebases, into the ExpressoTS framework. The objective is to automate the process of vulnerability detection, ensuring that ExpressoTS remains secure against known vulnerabilities in its dependencies and its own codebase. By implementing Snyk, we anticipate elevating the security standards of ExpressoTS, making it more robust and trustworthy for developers.

We will be using Snyk in combination with our current CodeQL implementation as well to cover a wider range of security risks

Objective

  • To automate vulnerability detection within the ExpressoTS codebase and its dependencies.
  • Ensure continuous security monitoring by integrating Snyk into our development and CI/CD pipelines.
  • Mitigate security risks by promptly addressing detected vulnerabilities, thereby protecting developers and end-users from potential exploits.

Requirements

  • Evaluate Snyk’s compatibility with the project’s existing tools and workflows.
    Snyk Integration:
  • Set up a Snyk account and integrate it with the ExpressoTS GitHub repository.
  • Configure Snyk to scan the codebase and dependencies for vulnerabilities automatically.
  • Integrate Snyk scans into the CI/CD pipeline, ensuring that every push and pull request is checked for vulnerabilities.
  • Establish criteria for failing builds based on the severity of detected vulnerabilities.
  • Provide guidelines for contributors on how to address vulnerabilities in their submissions.

Deploy to cloudflare workers

Is there an existing proposal similar to this?

  • I have searched the existing proposals

What are you proposing?

My idea is to create a new template in the core to implement a expressots template focusing cloudflare workers.

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

I will be honest, I think people who like to work with Cloudflare workers would benefit from this. I heard about Cloudflare workers about like 1 week ago while going through some open-source projects, and found myself using Cloudflare workers.

What problems are you trying to solve?

Trying to solve a new way to deploy expressots into cloudflare workers.

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

No I don't...

What type of idea is this?

Innovation: No similar idea exists

POC: Add Class Validator

Here is an example of class validator using class-validator package

export class Company {
  @IsDefined(tsDefaultDecorator("validation", "isNotEmpty"))
  @IsNotEmpty(tsDefaultDecorator("validation", "isNotEmpty"))
  @IsString(tsDefaultDecorator("validation", "isType", { type: "string" }))
  name: string;

  @IsOptional()
  @IsString(tsDefaultDecorator("validation", "isType", { type: "string" }))
  description: string;

  @IsDefined(tsDefaultDecorator("validation", "isNotEmpty"))
  @IsNotEmpty(tsDefaultDecorator("validation", "isNotEmpty"))
  @IsEnum(AssetTypes, tsEnumDecorator("validation", "isEnum", AssetTypes))
  type: AssetTypes;

  @IsDefined(tsDefaultDecorator("validation", "isNotEmpty"))
  @IsNotEmpty(tsDefaultDecorator("validation", "isNotEmpty"))
  @IsEnum(Countries, tsEnumDecorator("validation", "isEnum", Countries))
  country: Countries;

  @IsDefined(tsDefaultDecorator("validation", "isNotEmpty"))
  @IsNotEmpty(tsDefaultDecorator("validation", "isNotEmpty"))
  @IsEnum(StockExchanges, tsEnumDecorator("validation", "isEnum", StockExchanges))
  stockExchange: StockExchanges;

  @IsOptional()
  @IsString({
    each: true,
    ...tsDefaultDecorator("validation", "allArrayFields", { type: "string" }),
  })
  assets: string[];

  @IsOptional()
  @IsString()
  logoUrl: string;
}

Dependencies ownership

Dependencies ownership

To streamline the project and ensure it is more focused on our @core, it's essential to eliminate as many dependencies as possible. This will not only make the project more lean but also help to declutter any extraneous elements that aren't directly related to our @core.

Dependencies list

Based on the ease of implementation within the core, the following dependencies have been identified as removable. We will be linking each of these dependencies to their respective implementation issues, and if you're interested in contributing to any of these topics, please feel free to get in touch with @rsaz by leaving a comment in this issue or in the relevant issue pertaining to the specific dependency.

  • Logger (-)
  • Decorators
  • IOC
  • Dotenv (-)

Study of ExpressoTS framework running over Bun runtime

Overview

The objective of this study is to assess the compatibility and performance of the ExpressoTS framework when running on the Bun runtime environment. Bun is a modern JavaScript runtime similar to Node.js, but with a focus on improved performance and built-in bundling. As the ExpressoTS framework is primarily designed for Node.js environments, this study aims to explore the potential benefits, challenges, and modifications required to fully support Bun as a runtime option for ExpressoTS-based applications.

Goals

  • Compatibility Analysis: Evaluate the current compatibility of the ExpressoTS framework with the Bun runtime, identifying any immediate issues or limitations in functionality.
  • Performance Benchmarking: Compare the performance of ExpressoTS applications running on Bun versus Node.js, focusing on key metrics such as startup time, request handling speed, and resource utilization.
  • Feature Support: Determine the level of support for Bun-specific features within ExpressoTS applications, including but not limited to, Bun's built-in package manager, native TypeScript support, and enhanced module resolution.
  • Modification Requirements: Identify any necessary modifications or enhancements to the ExpressoTS framework to support running on Bun, including code changes, dependency updates, and configuration adjustments.
  • Documentation and Best Practices: Develop guidelines, documentation, and best practices for developers looking to run ExpressoTS applications on Bun, ensuring a smooth transition and optimal performance.

Specific Requirements

  • Environment Setup: Establish a testing environment for running ExpressoTS applications on both Bun and Node.js runtimes for direct comparison.
  • Test Suite Development: Design and implement a comprehensive test suite to assess functionality, compatibility, and performance across both runtime environments.
  • Benchmarking: Conduct systematic performance benchmarking under various conditions to gather empirical data comparing Bun and Node.js runtimes for ExpressoTS applications.
  • Feature Evaluation: Test the support and integration of Bun-specific features within the ExpressoTS framework, identifying any gaps or enhancements needed.
  • Documentation: Create detailed documentation covering the study's findings, including setup instructions, compatibility notes, performance comparison results, and any identified issues or workarounds.
  • Recommendation Report: Compile a final report summarizing the feasibility, benefits, and challenges of running ExpressoTS on Bun, including specific recommendations for framework modifications, developer guidelines, and potential use cases.

Deliverables

  • A detailed compatibility and performance report, including benchmarking data and analysis.
  • A list of required modifications or enhancements to the ExpressoTS framework to ensure compatibility with Bun.
  • Documentation and guidelines for developers on running ExpressoTS applications on Bun.
  • A recommendation report outlining the advisability and strategic considerations of supporting Bun as a runtime for ExpressoTS.
  • This study will play a crucial role in future-proofing the ExpressoTS framework, potentially opening up new avenues for performance optimization and feature enhancements by leveraging the Bun runtime environment.

The number of constructor arguments in the derived class Controller must be >= than the number of constructor arguments of its base class

Is there an existing issue for this?

  • I have searched the existing issues

Current behavior

When I create a controller without any useCases:

import { BaseController } from '@expressots/core'
import { controller, httpGet, response } from 'inversify-express-utils'

@controller('/health')
class HealthController extends BaseController {
  constructor() {
    super('health-controller')
  }

  @httpGet('/')
  execute(@response() res: any) {
    return res.send('alive')
  }
}

export { HealthController }

I've this error below:

[INFO] 21:49:15 Restarting: /home/thayto/projects/expresso/expressots-realworld-app/src/application/controllers/health.controller.ts has been modified
[2023-04-19 21:49:16] [core-api] [service-unknown] error: unhandledRejection: The number of constructor arguments in the derived class HealthController must be >= than the number of constructor arguments of its base class.
Error: The number of constructor arguments in the derived class HealthController must be >= than the number of constructor arguments of its base class.
    at /home/thayto/projects/expresso/expressots-realworld-app/node_modules/.pnpm/[email protected]/node_modules/inversify/src/planning/planner.ts:189:17
    at Array.forEach (<anonymous>)
    at _createSubRequests (/home/thayto/projects/expresso/expressots-realworld-app/node_modules/.pnpm/[email protected]/node_modules/inversify/src/planning/planner.ts:164:18)
    at plan (/home/thayto/projects/expresso/expressots-realworld-app/node_modules/.pnpm/[email protected]/node_modules/inversify/src/planning/planner.ts:240:5)
    at /home/thayto/projects/expresso/expressots-realworld-app/node_modules/.pnpm/[email protected]/node_modules/inversify/src/container/container.ts:623:25
    at Container._get (/home/thayto/projects/expresso/expressots-realworld-app/node_modules/.pnpm/[email protected]/node_modules/inversify/src/container/container.ts:574:37)
    at Container._getButThrowIfAsync (/home/thayto/projects/expresso/expressots-realworld-app/node_modules/.pnpm/[email protected]/node_modules/inversify/src/container/container.ts:580:25)
    at Container.getAll (/home/thayto/projects/expresso/expressots-realworld-app/node_modules/.pnpm/[email protected]/node_modules/inversify/src/container/container.ts:363:17)
    at getControllersFromContainer (/home/thayto/projects/expresso/expressots-realworld-app/node_modules/.pnpm/[email protected]/node_modules/inversify-express-utils/src/utils.ts:16:26)
    at InversifyExpressServer.registerControllers (/home/thayto/projects/expresso/expressots-realworld-app/node_modules/.pnpm/[email protected]/node_modules/inversify-express-utils/src/server.ts:149:56)

Steps to reproduce

  1. Create a crontroller withour any useCase on constructor
import { BaseController } from '@expressots/core'
import { controller, httpGet, response } from 'inversify-express-utils'

@controller('/health')
class HealthController extends BaseController {
  constructor() {
    super('health-controller')
  }

  @httpGet('/')
  execute(@response() res: any) {
    return res.send('alive')
  }
}

export { HealthController }

Expected behavior

Don't break the code and runs the app as usual

Package version

1.2.0

Node.js version

18.15.0

In which operating systems have you tested?

  • macOS
  • Windows
  • Linux

Other

Package Manager: PNPM
IDE: Neovim

Linter is not working until we setup the husky

Is there an existing issue for this?

  • I have searched the existing issues

Current behavior

Currently, without execution of npm run prepare, we see that husky for the project is not auto setup. This basically an additional setup for the developer after installation, which might be missed most of the time.

Steps to reproduce

  1. Clone the code
  2. npm install
  3. start working and make commits, you would pre commit hooks are not working

Expected behavior

Ideally pre commit hooks should be setup as soon as project setup is done automatically without causing any overhead for developer to set it up.

Package version

@expressots/*

Node.js version

@expressots/*

In which operating systems have you tested?

  • macOS
  • Windows
  • Linux

Other

Solution:

Add a script in package.json:

...
"postinstall": "npm run prepare"
...

This ensures that the pre commit hooks is auto setup after completion of the npm install

Implement JWT Provider

Description

This task involves creating a JWT (JSON Web Token) Provider within the ExpressoTS framework. The provider will be responsible for generating, verifying, and managing JWTs, which are critical for secure authentication and authorization processes. While jsonwebtoken is suggested, the developer is encouraged to evaluate and propose any superior alternatives.

Goals

  • Secure Token Management: The JWT provider should ensure tokens are generated and managed securely, incorporating best practices to prevent common security vulnerabilities.
  • Ease of Use: It should offer a simple and straightforward interface for other components within the framework to generate and verify tokens.
  • Flexibility: The provider must be configurable to accommodate different use cases and security requirements.

Requirements

Provider Setup:

  • Evaluate the jsonwebtoken library and any other potential libraries for JWT management. Select the most suitable option based on features, security, performance, and community support.
  • Create a new provider class that adheres to the IProvider interface from the ExpressoTS core.

Token Generation:

  • Implement a method for generating JWTs with support for custom claims and expiration settings.
  • Ensure the generation process is compliant with the latest security standards for token-based authentication.

Token Verification:

  • Provide a method for verifying JWTs, including signature validation and claim checks.
  • Handle common JWT verification issues gracefully, providing meaningful error messages.

Configuration:

  • Allow for easy configuration of token secret keys, algorithm selection, and other JWT settings through environment variables or configuration files.

Testing:

  • Develop a comprehensive test suite to verify token generation, expiration, signature validation, and error handling.
  • Include tests for different configuration scenarios to ensure flexibility and robustness.

Documentation:

  • Document the provider’s methods, configurations, and usage within the ExpressoTS framework.
  • Provide sample code and use-case scenarios to guide developers on how to utilize the JWT provider for authentication and authorization.

Integration:

  • Ensure the provider integrates seamlessly with the ExpressoTS authentication and authorization mechanisms.
  • The JWT provider should be easy to plug into existing applications built on the ExpressoTS framework with minimal configuration.

Deliverables

  • A fully implemented JWT provider compatible with the ExpressoTS framework.
  • A detailed report comparing jsonwebtoken with any other evaluated libraries, justifying the selection.
  • A test suite covering all aspects of the JWT provider.
  • Comprehensive documentation and usage examples.

feat: Global Error Handler and Response envelope as middleware

Is there an existing proposal similar to this?

  • I have searched the existing proposals

What are you proposing?

Proposal Description:

  • Implement a custom middleware for handling the Error handling at the global level and also add response handler as well based on the use case of the API.
  • Currently, we have to make custom middlewares as part of the user defined middlewares. This change would ensure that framework itself provides with a custom handler and people can simply override it and add custom handler as per their requirements.

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

NA

What problems are you trying to solve?

Problems resolved:

  • Creating custom error handler and response handler
  • Generalization of response envelope and error response wrapper

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

This implementation is JS version implemented in express.js framework, similar bit can be added in expressots as default or optional behavior internally.

What type of idea is this?

Innovation: No similar idea exists

Implement Helmet Middleware

Is there an existing issue for this?

  • I have searched the existing issues

Current behavior

We have a middleware service where we do add services that can be used dynamically by the developer during the application development like so:

@provide(App)
export class App extends AppExpress {
    private middleware: IMiddleware;
    private provider: IProvider;

    constructor() {
        super();
        this.middleware = container.get<IMiddleware>(Middleware);
        this.provider = container.get<IProvider>(Provider);
    }

    protected configureServices(): void {
        this.middleware.addBodyParser();
        this.middleware.setErrorHandler();
    }

    protected postServerInitialization(): void {
        if (this.isDevelopment()) {
            this.provider.envValidator.checkAll();
        }
    }

    protected serverShutdown(): void {}
}

The middleware are added in the middleware service as mentioned above as well as it's interfaces implemented here.
The interfaces are the options that can be optionally passed to the middleware.

This task has the objective of implementing the middleware Helmet embedded in the ExpressoTS platform as the other middlewares.

More information here: https://github.com/helmetjs/helmet

Steps to reproduce

N/A

Expected behavior

Helmet as an option in middleware service

Package version

2.2.1

Node.js version

18

In which operating systems have you tested?

  • macOS
  • Windows
  • Linux

Other

No response

POC: Transitioning to decorator-based module system

Description

To study the replacement of the current module registration and dependency injection system with a decorator-based approach.
The existing mechanism, which relies on explicit imports and manual module registration via Container from "inversify" and AppContainer from "@expressots/core", has served us well but lacks the simplicity and elegance that decorators can provide. By adopting decorators, we aim to streamline the module system, improve developer experience, and align with modern TypeScript best practices.

Proposed Decorator-Based Approach

@container Decorator: This decorator can be used to mark a class as a container that can contain modules.

Current approach:

export const appContainer: AppContainer = new AppContainer({
    autoBindInjectable: false,
});

export const container: Container = appContainer.create([
    // Add your modules here
    AppModule,
]);

Proposed new approach

@Container({
    config: {
        autoBindInjectable: false,
        defaultScope: BindingScopeEnum.Transient,
        skipBaseClassChecks: true,
    },
    modules: [],
})
export class AppContainer {}

To be used in the bootstrap:

async function bootstrap() {
    const app = await AppFactory.create(AppContainer, App);
    await app.listen(3000, ServerEnvironment.Development);
}

Benefits

  • @container Decorator Improvements: We enhance the @container decorator to accept a configuration object. This decorator is responsible for marking a class as the root container for the application, allowing for centralized configuration of the dependency injection container options and registered modules.
  • Module Registration: We can further simplify module registration by allowing the @container decorator to automatically include modules listed in its modules array, reducing manual setup.
  • Simplified Bootstrap Function: The bootstrap function becomes cleaner, focusing solely on application initialization and setup, without directly dealing with container configuration details.

Automating Environment Configuration Selection Based on ServerEnvironment Enum

Description

We aim to enhance the current system for managing environment configurations in our application by automatically selecting the appropriate .env file (env.prod for production or env.local for local development) based on a ServerEnvironment enum. This will streamline the setup process for different environments, reducing manual intervention and potential human error. Additionally, we seek suggestions for modernizing our approach to environment configuration management, ensuring our system is robust, flexible, and easy to maintain.

Current Approach

The application currently loads .env.local explicitly within the EnvironmentProvider class, without considering the environment context (Production, Development, etc.) dynamically. Here is the simplified current implementation:

async function bootstrap() {
    const app = await AppFactory.create(container, App);
    await app.listen(3000, ServerEnvironment.Production);
}

@provide(EnvironmentProvider)
export class EnvironmentProvider {
    async load(): Promise<void> {
        try {
            const fs = import("fs");
            const configPath = ".env.local";
            if ((await fs).existsSync(configPath)) {
                const local = (await import("dotenv")).config({
                    path: configPath,
                });
                process.env = {
                    ...process.env,
                    ...local.parsed,
                };
            }
        } catch {}
    }
}

Objective

Automate .env File Selection: Based on the ServerEnvironment enum passed during the application bootstrap process, automatically determine and load the corresponding .env file (env.prod or env.local).
Modernize Configuration Management: Explore and suggest modern approaches or tools that could offer a more flexible, secure, and maintainable way to manage environment configurations.

Requirements

Dynamic Environment Configuration
Implement logic to dynamically select the .env file based on the ServerEnvironment enum.
Ensure seamless transition between environments without manual file swapping or code changes.

Error Handling and Logging
Improve error handling around environment file loading to ensure clarity and traceability of issues.
Enhance logging to provide clear feedback on which environment configuration is loaded.
Exploration of Modern Tools and Practices:

Research and suggest modern tools or libraries that could improve environment configuration management (e.g., support for .env file encryption, advanced parsing capabilities).
Consider adopting a library or framework that natively supports different environment configurations without manual intervention.

Examples

// Assuming ServerEnvironment is accessible and used to determine the environment
const environmentConfig = {
    [ServerEnvironment.Production]: '.env.prod',
    [ServerEnvironment.Development]: '.env.local',
    // Add other environments as needed
};

const configPath = environmentConfig[process.env.NODE_ENV] || '.env.local'; // Default to local

// Load the appropriate .env file based on the current environment
const dotenv = require('dotenv');
dotenv.config({ path: configPath });

Modern Approaches

Centralized Configuration Service
For applications running in microservices or requiring dynamic configuration across multiple environments, consider using a centralized configuration service like Spring Cloud Config, Consul, or etcd. These tools can serve environment-specific configurations at runtime, reducing the need for local .env files and enabling real-time configuration changes without redeployment.

Environment Variables Management Tools
Tools like HashiCorp Vault or AWS Secrets Manager offer more secure ways to manage environment variables, especially secrets. They provide encryption, access control, and audit logs, which are particularly useful for production environments.

Containers and Orchestration
If your application runs in containers, consider using Docker or Kubernetes for environment configuration. Both allow you to manage environment variables securely and flexibly through container orchestration, supporting different environments without changing the codebase.

For Docker, you might use docker-compose with environment-specific override files (docker-compose.prod.yml, docker-compose.dev.yml) to define and manage environment variables.

Utilize Modern Frameworks or Libraries
Some newer frameworks or libraries are designed with environment management in mind. For example, Next.js (for React applications) automatically loads .env.local or .env.[environment] files based on the NODE_ENV value, without additional setup. Exploring such options can provide out-of-the-box solutions for environment configuration management.

Suggestions

Take in consideration of the new built-in .env file in node v21
https://nodejs.org/en/blog/release/v20.6.0

Also, look at how .net core applications deals with multiple environment.
https://learn.microsoft.com/en-us/aspnet/core/fundamentals/environments?view=aspnetcore-8.0

Add code coverage action

Description

Code coverage is a metric used in software development to measure the extent to which a software program's source code has been executed or covered by a set of tests

Since the tests are running correctly in the CI, we should add a code coverage action to assert that every (or almost) new feature is going to be tested.

Possible Implementations

Codecov can be a good option, it is free for use on open-source and provides a great set of tools.

Refs.:
https://about.codecov.io/
https://github.com/marketplace/codecov/plan/MDIyOk1hcmtldHBsYWNlTGlzdGluZ1BsYW4xNg==#pricing-and-setup

Requirements

  • code coverage added to Github workflow.
  • add the shield badge in the doc
  • minimum code coverage 80% with exceptions

Definition of Done

  • action running correctly in the PR.
  • action running correctly on merge

Development of a VSCODE Extension for ExpressoTS App and resources scaffolding

Description

The goal of this issue is to conceptualize, design, and implement a Visual Studio Code extension specifically tailored for the ExpressoTS framework. This extension will enable developers to quickly scaffold new ExpressoTS applications directly from VSCODE, with a variety of customizable options including authentication schemes, database integrations, UI frameworks (Vue, React, Angular), and ORM configurations. This tool aims to significantly reduce the setup time for new projects and provide a seamless, guided experience for configuring advanced features and integrations.

Objective

  • Streamline the ExpressoTS application setup process by offering a VSCODE extension that guides users through creating a new project with various configuration options.
  • Enhance developer experience with an interactive, user-friendly interface that simplifies complex setup decisions.
  • Promote adoption of the ExpressoTS framework by making it more accessible and easier to start with for new users.

Requirements

  • A fully functional VSCODE extension that can be easily installed and used to scaffold ExpressoTS projects with various customization options.
  • A significant reduction in initial project setup time and complexity, making it easier for developers to start building with ExpressoTS.
  • Enhanced visibility and adoption of the ExpressoTS framework within the developer community.

Implement middleware Multer

Is there an existing issue for this?

  • I have searched the existing issues

Current behavior

We have a middleware service where we do add services that can be used dynamically by the developer during the application development like so:

@provide(App)
export class App extends AppExpress {
    private middleware: IMiddleware;
    private provider: IProvider;

    constructor() {
        super();
        this.middleware = container.get<IMiddleware>(Middleware);
        this.provider = container.get<IProvider>(Provider);
    }

    protected configureServices(): void {
        this.middleware.addBodyParser();
        this.middleware.setErrorHandler();
    }

    protected postServerInitialization(): void {
        if (this.isDevelopment()) {
            this.provider.envValidator.checkAll();
        }
    }

    protected serverShutdown(): void {}
}

The middleware are added in the middleware service as mentioned above as well as it's interfaces implemented here.
The interfaces are the options that can be optionally passed to the middleware.

This task has the objective of implementing the middleware Multer embedded in the ExpressoTS platform as the other middlewares.

More information here: https://expressjs.com/en/resources/middleware/multer.html

Steps to reproduce

N/A

Expected behavior

Multer implemented as an option in middleware service

Package version

2.2.1

Node.js version

18

In which operating systems have you tested?

  • macOS
  • Windows
  • Linux

Other

No response

Scaffold of Middleware from CLI

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

Reimplement DB In Memory Provider

Overview

The objective of this task is to reimplement the InMemoryDB provider to enhance its usability and functionality for developers using the ExpressoTS framework. The InMemoryDB class serves as a simple yet powerful tool for simulating a database in memory, ideal for development and testing environments where connection to a real database is not feasible or necessary. This reimplementation aims to introduce improvements that will make the InMemoryDB more intuitive to use, extend its capabilities, and improve its integration within the ExpressoTS ecosystem.

Goals

  • Enhanced Usability: Simplify the API and improve the documentation to make the InMemoryDB easier to use for developers.
  • Extended Functionality: Add new features to the InMemoryDB, such as query support, more complex data manipulation, and event hooks.
  • Improved Integration: Ensure seamless integration with the ExpressoTS framework, enhancing the developer experience when using InMemoryDB in conjunction with other framework features.
  • Performance Optimization: Optimize the performance of the InMemoryDB for faster data access and manipulation, particularly for large datasets.

Requirements

API Usability Improvements:

  • Conduct a review of the current API, identifying areas for simplification or enhancement.
  • Redesign the API as necessary to make it more intuitive, ensuring backward compatibility where possible.
  • Update or expand the in-code documentation to provide clear usage examples and best practices.

Feature Extensions:

  • Implement support for basic query operations (e.g., find, filter, sort) to allow more flexible data retrieval.
  • Add support for more complex operations such as join-like functionalities or aggregations, if feasible.
  • Introduce event hooks or callbacks for common operations (e.g., onAdd, onUpdate, onDelete) to allow custom logic execution.

Integration with ExpressoTS:

  • Ensure the InMemoryDB can be easily registered and configured within the ExpressoTS framework, following the framework's conventions and patterns.
  • Explore and implement mechanisms for easy setup of initial data or schema definitions, enhancing the development workflow.

Performance Optimization:

  • Profile the current implementation to identify performance bottlenecks.
  • Implement optimizations to improve data access and manipulation speeds, especially for operations involving large datasets.
  • Ensure that the reimplementation does not significantly increase memory usage.

Testing and Validation:

  • Develop a comprehensive test suite covering all new functionalities and potential edge cases.
  • Validate the InMemoryDB's integration with the ExpressoTS framework through end-to-end tests.

Documentation and Examples:

  • Provide detailed documentation for the reimplemented InMemoryDB, including setup instructions, API reference, and examples of common use cases.
  • Include examples demonstrating the integration of InMemoryDB with ExpressoTS framework features, highlighting its use in development and testing scenarios.

Implement Unit test for Core

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

Image

Requirements

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

Implement Session Middleware

Is there an existing issue for this?

  • I have searched the existing issues

Current behavior

We have a middleware service where we do add services that can be used dynamically by the developer during the application development like so:

@provide(App)
export class App extends AppExpress {
    private middleware: IMiddleware;
    private provider: IProvider;

    constructor() {
        super();
        this.middleware = container.get<IMiddleware>(Middleware);
        this.provider = container.get<IProvider>(Provider);
    }

    protected configureServices(): void {
        this.middleware.addBodyParser();
        this.middleware.setErrorHandler();
    }

    protected postServerInitialization(): void {
        if (this.isDevelopment()) {
            this.provider.envValidator.checkAll();
        }
    }

    protected serverShutdown(): void {}
}

The middleware are added in the middleware service as mentioned above as well as it's interfaces implemented here.
The interfaces are the options that can be optionally passed to the middleware.

This task has the objective of implementing the middleware Session embedded in the ExpressoTS platform as the other middlewares.

More information here: https://expressjs.com/en/resources/middleware/session.html

Steps to reproduce

N/A

Expected behavior

Implemented express session middleware and make it available as an option in the application provider class

Package version

2.5.0

Node.js version

18

In which operating systems have you tested?

  • macOS
  • Windows
  • Linux

Other

N/A

Implement Passport Middleware

Is there an existing issue for this?

  • I have searched the existing issues

Current behavior

We have a middleware service where we do add services that can be used dynamically by the developer during the application development like so:

@provide(App)
export class App extends AppExpress {
    private middleware: IMiddleware;
    private provider: IProvider;

    constructor() {
        super();
        this.middleware = container.get<IMiddleware>(Middleware);
        this.provider = container.get<IProvider>(Provider);
    }

    protected configureServices(): void {
        this.middleware.addBodyParser();
        this.middleware.setErrorHandler();
    }

    protected postServerInitialization(): void {
        if (this.isDevelopment()) {
            this.provider.envValidator.checkAll();
        }
    }

    protected serverShutdown(): void {}
}

The middleware are added in the middleware service as mentioned above as well as it's interfaces implemented here.
The interfaces are the options that can be optionally passed to the middleware.

This task has the objective of implementing the middleware Passport embedded in the ExpressoTS platform as the other middlewares.

More information here: https://github.com/jaredhanson/passport

Steps to reproduce

N/A

Expected behavior

Implemented passport middleware and make it available as an option in the application provider class

Package version

2.2.1

Node.js version

18

In which operating systems have you tested?

  • macOS
  • Windows
  • Linux

Other

No response

Unable to inject dependency on Application

Is there an existing issue for this?

  • I have searched the existing issues

Current behavior

Created a provider called "EventManager" and tried inject it on Application class to be invoked on postServerInitialization()

2023-07-25_14-50

But received this error on start the server:

2023-07-25_14-50

Steps to reproduce

  1. npm ci
  2. npm run dev

Expected behavior

2023-07-25_14-50

Package version

1.5.1

Node.js version

18.14.0

In which operating systems have you tested?

  • macOS
  • Windows
  • Linux

Other

di-issue.zip

new opinionated project pnpm, dev won't start w/ typescript error

Is there an existing issue for this?

  • I have searched the existing issues

Current behavior

after
expressots new home-photos pnpm opinionated
and
pnpm run dev
I get

[INFO] 15:09:23 ts-node-dev ver. 2.0.0 (using ts-node ver. 10.9.1, typescript ver. 4.9.5)
Compilation error in /Users/joe/Projects/home-photos/src/useCases/app/app.controller.ts
[ERROR] 15:09:24 ⨯ Unable to compile TypeScript:
src/useCases/app/app.controller.ts(14,9): error TS2322: Type 'Response<any, Record<string, any>>' is not assignable to type 'string'.

Steps to reproduce

  1. expressots new home-photos pnpm opinionated
  2. pnpm run dev

Expected behavior

something works without a typescript error

Package version

1.5.0-dev

Node.js version

20.4.0

In which operating systems have you tested?

  • macOS
  • Windows
  • Linux

Other

1.5.0-dev came up because OOB the cli seems to ask for '@latest'.

Refactor AppFactory

Description

AppFactory currently supports scenarios for opinionated and non-opinionated templates such as passing an array of middlewares in the server construction. Now all templates supports app.provider constructor, making unnecessary code conditions for Expressjs and Fastify on factory class.

Requirements

  • Review AppFactory class and simplify allowing the creation of new servers as long as they comply with the interface
  • Review Express Adapter to make sure container always gets created first in order to make any other symbol available

Enhancement: Extend Expresso Configuration for Prisma Provider Integration

Current Behavior:
In the current version of Expresso, the configuration for scaffolding and opinionated settings is limited to a basic setup. While this setup works well for many use cases, it lacks support for seamless integration with the Prisma provider, making it harder to manage the schema, entities, and related configurations.

Proposed Enhancement:
I would like to propose an enhancement to the Expresso configuration to include a dedicated section for integrating the Prisma provider. This enhancement would allow users to define specific settings related to the Prisma provider, such as schema location, entity paths, naming patterns, and more.

Example:

Before:

import { ExpressoConfig, Pattern } from "@expressots/core";

const config: ExpressoConfig = {
    sourceRoot: "src",
    scaffoldPattern: Pattern.KEBAB_CASE,
    opinionated: true,
};

export default config;

After:

import { ExpressoConfig, Pattern } from "@expressots/core";

const config: ExpressoConfig = {
    sourceRoot: "src",
    scaffoldPattern: Pattern.KEBAB_CASE,
    opinionated: true,
    providers: {
        Prisma: {
            schemaName: "schema.prisma",
            schemaPath: "providers/prisma",
            entitiesPath: "src/entities",
            entityNamePattern: "entity",
        },
    },
};

export default config;

Related Issue:
This enhancement proposal is related to improving the Expresso CLI and configuration options to better support third-party providers such as Prisma.

POC: E2E testing module for ExpressoTS

Description

The goal of this issue is to research and develop a prototype for a new component within the ExpressoTS framework, namely @expressots/test. This component aims to streamline both unit and end-to-end (E2E) testing processes for developers, providing a universal interface that can be integrated with any testing framework such as Jest, Vitest, or Playwright. The core of this initiative is to create a generic, yet powerful, testing module that leverages decorators and other advanced capabilities to facilitate a seamless testing experience.

Objective

  • To prototype a generic testing module that abstracts the complexities involved in setting up and executing tests, making it easier for developers to write and maintain their test suites.
  • Ensure compatibility with leading testing frameworks (e.g., Jest, Vitest, Playwright) to allow developers the flexibility to choose their preferred tools without sacrificing functionality.
  • Streamline the testing workflow by introducing decorators and utilities that simplify common tasks such as mocking, spying, and test data management.

Requirements

Research & Compatibility

  • Conduct a thorough analysis of existing testing frameworks to identify common patterns, functionalities, and pain points experienced by developers.
  • Ensure the solution is framework-agnostic, offering a consistent API/interface that works seamlessly across Jest, Vitest, Playwright, etc.

Design & Architecture

  • Design a modular architecture for @expressots/test that allows for easy expansion and integration with different testing frameworks and tools.
  • Develop a set of decorators and utilities that can be universally applied to manage test lifecycle hooks, mocks, spies, and assertions.

Implementation

  • Prototype the core functionalities of @expressots/test, focusing on simplicity of use and extensibility.
  • Implement a series of basic unit and E2E test examples demonstrating the capabilities and ease of use of the new module.

Documentation & Examples

  • Provide comprehensive documentation covering setup, configuration, and examples of using @expressots/test with different testing frameworks.
  • Document best practices and provide guidance on how to effectively leverage the module to maximize testing efficiency and coverage.

Feedback Loop

  • Establish a mechanism for gathering user feedback on the prototype to guide further development and refinement.

Expected Outcomes

  • A functional prototype of @expressots/test that demonstrates its capabilities in streamlining the testing process.
  • Detailed documentation and examples that enable developers to easily integrate the module into their existing projects.
    An actionable plan based on user feedback for further development and enhancement of the module.

Bodyparsers entity large

Is there an existing issue for this?

  • I have searched the existing issues

Current behavior

Big payload cause bug entity large in body-parser

Steps to reproduce

No response

Expected behavior

{
"_id": "gengar",
"logs": [
"a",
"b"
],
"userName": "asancodigos",
"_playerId": "x",
"winner": false,
"pokemon1": "444beaed-f246-4011-a36a-257370055586",
"pokemon2": "pikachu"
}

Package version

1.2.0

Node.js version

18.13.0

In which operating systems have you tested?

  • macOS
  • Windows
  • Linux

Other

No response

Alter the HTTP Decorators to set the default status code upon return a request

Description

The purpose of this task is to modify the existing HTTP decorators (@get, @post, @put, @patch, @Head, @delete) used in the ExpressoTS framework to automatically set appropriate default HTTP status codes when a controller method returns a response. This enhancement aims to streamline response handling by ensuring that common HTTP response status codes are automatically applied based on the type of request, thereby reducing boilerplate code and potential for error.

Goals

  • Automation of Response Codes: Automatically set HTTP response codes that are typical for each type of request to improve consistency across the application.
  • Reduction in Manual Code: Decrease the need for developers to manually set status codes in every controller method.
  • Compliance with HTTP Standards: Ensure that the implementation adheres to standard HTTP practices for response codes.

Requirements

Decorator Enhancements:

  • Modify the @post decorator to automatically set the HTTP status code to 201 (Created) unless otherwise specified.
  • Ensure that the @get, @put, @patch, and @delete decorators set appropriate default status codes like 200 (OK), 204 (No Content) for no-return methods, or others as relevant.
  • Allow decorators to accept an optional parameter to override the default status code if a custom response is needed.

Integration with Controller Methods:

  • Ensure that the enhanced decorators correctly interact with the controller methods to set the specified or default HTTP status codes based on the action performed.
  • Validate the correct status code setting even when the methods are asynchronous or involve complex logic.

Testing and Validation:

  • Develop comprehensive tests to ensure that the correct status codes are automatically set for each type of HTTP method.
  • Include tests for scenarios where the default status codes are overridden by custom codes provided by developers.

Documentation:

  • Update the documentation for the HTTP decorators to include information about the default status codes.
  • Provide guidelines on how to override the default status codes with custom values when necessary.

Backward Compatibility:

  • Ensure that these changes do not break existing implementations where specific status codes are manually set within the controllers.
  • Provide a clear migration path for updating existing code to the new decorator system.

Deliverables

  • Updated HTTP decorators with automatic status code setting capabilities.
  • A suite of tests confirming the functionality and robustness of the new decorator behavior.
  • Comprehensive documentation detailing the changes, usage examples, and migration guide for existing codebases.
  • This task will significantly enhance the developer experience by automating a common repetitive task, ensuring consistency, and reducing the potential for errors in HTTP status code management within the ExpressoTS framework.

CLI opinionated - user use-cases should return NotFound, not BadRequest

Is there an existing issue that is already proposing this?

  • I have searched the existing issues

Is your feature request related to a problem? Please describe it

Reading the source code of opinionated, I found i had an opinionated bit of feedback. :)

The headers for not finding the user in Find, Update, Delete all return 400 Bad Request when the user isn't in the db. They should return 404 to follow the http standard.

Describe the feature you'd like

Standard REST header for an endpoint not finding the asset being requested (presuming this isn't a search) is to return 404 NotFound. 400 BadRequest should be reserved for cases where the parameters of a query are actually incorrect to the data or the endpoint (e.g., if your id's were numbers (db sequence id's) and the user sent a request for id of Fred).

Create is fine with a 400 when the inputs are incorrect. The Find, Update, and Delete are the ones I'd suggest to update.

Teachability, documentation, adoption, migration strategy

Just setting a good example for using the HTTP headers properly.

What is the motivation / use case for changing the behavior?

Just setting a good example for using the HTTP headers properly.

Missing the start script in package.json

Is there an existing issue for this?

  • I have searched the existing issues

Current behavior

I am trying to run the project, to make some contribution, but I have no clue about how to run the project.

And run the project in development mode with:

npm start

Ok, sounds good, but when I open package.json, there is no start script. Any clue?
image

Steps to reproduce

No response

Expected behavior

supposed to have the start script in package.json

Package version

1.2.0

Node.js version

19.8.1

In which operating systems have you tested?

  • macOS
  • Windows
  • Linux

Other

No response

Remove "should" from test labels

Generating service from CLI is not picking up the correct controller folder

Is there an existing issue for this?

  • I have searched the existing issues

Current behavior

When trying to generate a service using CLI

expressots g s player-create

The folder structure gets created correctly as shown in the image attached
image

however the module is not picking up the correct folder from where the controller is coming from
image

Steps to reproduce

  1. using the scaffold entity-action method
  2. code
expressots g s player-create
  1. error
import { CreateModule } from "@expressots/core";
import { PlayerCreateController } from ".//player-create.controller";

const PlayerModule = CreateModule([PlayerCreateController]);

export { PlayerModule };

Expected behavior

Should be

import { PlayerCreateController } from "./create/player-create.controller";

Package version

1.5.1

Node.js version

18.12.1

In which operating systems have you tested?

  • macOS
  • Windows
  • Linux

Other

CLI 1.3.1

Remove the inversify-binding-decorators dependency from templates

Description

Remove the dependency of inversify-binding-decorators library from the templates. Currently the only functionality in used from this library is the @provide decorator. All the other decorators such as @provideSingleton and @provideTransient

In this task, core will provide the decorators as an abstraction from inversify-bindings as we currently do for provide singleton and request.

The @provide decorators should be moved to the decorator folder in the core.
Before moving this piece of functionality, analyze other functionalities from the library such as:

  • Fluent api binding decorator
  • using provide multiple times
  • using symbols as identifies
  • creating alias
  • auto provide utility

Requirements

Objective: Eliminate the reliance on the inversify-binding-decorators library by incorporating the @provide decorator's functionality into the core module of the framework. Ensure all existing functionalities related to dependency injection and service provision are preserved and efficiently integrated into the core architecture.

Conduct a thorough review of the inversify-binding-decorators library, specifically focusing on:

  • The @provide decorator usage.
  • The utility of additional decorators such as @provideSingleton and @provideTransient, ensuring these are already abstracted within the core.
  • Other features including fluent API binding, multiple uses of @provide, symbol as identifiers, alias creation, and the auto-provide utility.
  • Decorator Integration:
  • Migrate the @provide decorator to the core/decorator folder. Ensure this migration includes not just the relocation of code but also the adaptation of the decorator to fit the core module’s architecture and conventions.

Compatibility and Extension:

  • Design the integrated @provide decorator to be fully compatible with the core module’s existing dependency injection mechanisms.
  • Ensure the decorator supports all the analyzed functionalities from the inversify-binding-decorators library that are deemed necessary and beneficial for the core module.

Testing:

  • Develop comprehensive tests to verify the @provide decorator's functionality within the core module. Tests should cover:
    Standard usage scenarios.
  • Advanced scenarios identified during the functionality analysis (e.g., using symbols as identifiers, creating aliases).
  • Compatibility with existing @provideSingleton and @provideTransient functionalities.

Documentation:

  • Update the project documentation to reflect the removal of the inversify-binding-decorators dependency and the integration of the @provide decorator into the core.
  • Provide clear examples and guidance on using the new core-based @provide decorator, including any new features or syntax introduced.

Website ChunkLoadErrors

Is there an existing issue for this?

  • I have searched the existing issues

Current behavior

website is extremely slow due to ChunkLoadErrors
Did not seem to be caused by privacy badger, which when activated does throw some errors:

With privacy badger on by default:
Screenshot 2023-08-30 at 23 36 49
Screenshot 2023-08-30 at 23 36 41

privacy badger off:
Screenshot 2023-08-30 at 23 37 25

Screenshot 2023-08-30 at 23 36 59

Steps to reproduce

go to website

Expected behavior

fast website!

Package version

Node.js version

In which operating systems have you tested?

  • macOS
  • Windows
  • Linux

Other

mac OSX Big Sur 11.7.8 / chrome@Version 114.0.5735.198 (Official Build) (x86_64)

Run the app, with opinionated template, in dev mode

Is there an existing issue for this?

  • I have searched the existing issues

Current behavior

Running new project in mod dev.

Steps to reproduce

  1. Create a new project expressots new expressots-api -t opinionated -p yarn
  2. Create a new .env file based on .env.example
  3. yarn run dev

Expected behavior

Start the application.

Package version

1.4.2

Node.js version

19.8.1

In which operating systems have you tested?

  • macOS
  • Windows
  • Linux

Other

➜  yarn run dev
yarn run v1.22.19
$ tsnd -r dotenv/config -r tsconfig-paths/register ./src/main.ts
[INFO] 20:25:07 ts-node-dev ver. 2.0.0 (using ts-node ver. 10.9.1, typescript ver. 4.9.5)
[2023-06-29 20:25:10] [core-api] [env-validator-provider] info: Environment variable GTK_EXE_PREFIX_VSCODE_SNAP_ORIG is not defined.
[2023-06-29 20:25:10] [core-api] [env-validator-provider] info: Environment variable GDK_BACKEND_VSCODE_SNAP_ORIG is not defined.
[2023-06-29 20:25:10] [core-api] [env-validator-provider] info: Environment variable LOCPATH_VSCODE_SNAP_ORIG is not defined.
[2023-06-29 20:25:10] [core-api] [env-validator-provider] info: Environment variable GSETTINGS_SCHEMA_DIR_VSCODE_SNAP_ORIG is not defined.
[2023-06-29 20:25:10] [core-api] [env-validator-provider] info: Environment variable XDG_CONFIG_DIRS_VSCODE_SNAP_ORIG is not defined.
[2023-06-29 20:25:10] [core-api] [env-validator-provider] info: Environment variable GIO_MODULE_DIR_VSCODE_SNAP_ORIG is not defined.
[2023-06-29 20:25:10] [core-api] [env-validator-provider] info: Environment variable GTK_PATH_VSCODE_SNAP_ORIG is not defined.
[2023-06-29 20:25:10] [core-api] [env-validator-provider] info: Environment variable GTK_IM_MODULE_FILE_VSCODE_SNAP_ORIG is not defined.
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

Implement Expressjs Rate Limit Middleware

Is there an existing issue for this?

  • I have searched the existing issues

Current behavior

We have a middleware service where we do add services that can be used dynamically by the developer during the application development like so:

@provide(App)
export class App extends AppExpress {
    private middleware: IMiddleware;
    private provider: IProvider;

    constructor() {
        super();
        this.middleware = container.get<IMiddleware>(Middleware);
        this.provider = container.get<IProvider>(Provider);
    }

    protected configureServices(): void {
        this.middleware.addBodyParser();
        this.middleware.setErrorHandler();
    }

    protected postServerInitialization(): void {
        if (this.isDevelopment()) {
            this.provider.envValidator.checkAll();
        }
    }

    protected serverShutdown(): void {}
}

The middleware are added in the middleware service as mentioned above as well as it's interfaces implemented here.
The interfaces are the options that can be optionally passed to the middleware.

This task has the objective of implementing the middleware express-rate-limit embedded in the ExpressoTS platform as the other middlewares.

More information here: https://github.com/express-rate-limit/express-rate-limit

Steps to reproduce

N/A

Expected behavior

Implemented express-rate-limit middleware and make it available as an option in the application provider class

Package version

2.2.1

Node.js version

18

In which operating systems have you tested?

  • macOS
  • Windows
  • Linux

Other

No response

Opinionated template error on internal empty environment variable

Opinionated template error on internal empty environment variable

Problem

If the user has a internal environment variable that's empty it will not allow the program to load until it has some value

Environment (PC)

  • Kernel: Linux 6.1.12-artix1-1
  • Shell: ZSH
  • Package manager: yarn 1.22.19
  • Expresso version: 1.0.0

Add vitest config

Description

We need automated tests as soon as possible in the core. Tests ensure not only quality but also accelerate development, a strong culture of automated testing makes the team more agile and with more bug-free deliveries.

We already have some tests ( e.g. https://github.com/expressots/expressots/blob/main/packages/core/test/application.spec.ts), but they are not running correctly.

The goal of this issue is to fix the config and enable tests to run, it also should use Vitest instead of Jest, they are almost the same in terms of syntax. However, Vitest is much faster.

Ref.
https://vitest.dev/
https://vitest.dev/config/
https://dev.to/mbarzeev/from-jest-to-vitest-migration-and-benchmark-23pl

Requirements

  • vite and vitest must be listed in the project references;
  • all tests must run;
  • tests must run in the CI.

Definition of Done

  • assert that tests are running correctly using vitest;
  • assert that the action is correctly running in the PR.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.