Skip to content

Latest commit

 

History

History
111 lines (86 loc) · 5.43 KB

CONTRIBUTING.md

File metadata and controls

111 lines (86 loc) · 5.43 KB
Raw

Contributing

Antes de contribuir en este repositorio, por favor

Crea un issue planteando el problema a resolver y espera una respuesta.
Sé amable en la discusión y permite que los desarrolladores principales ofrezcan su ayuda para resolver los problemas.
Siéntete libre de crear cualquier issue que tengas en mente. Todas las ideas son bienvenidas, pero asegúrate que ésta no haya sido planteada con anterioridad.

Objetivo

El objetivo de Lepp es ofrecer al programador final una interfaz sencilla.
Inventemos un lema, algo así como
A mayor complejidad, menos código.

La interfaz en cuestión es la clase Lepp. Con esta se debe poder configurar todo el servidor, mediante la menor cantidad de métodos y propiedades posibles.
Principalmente la clase debe estar perfectamente documentada mediante JSDoc, y testeada con Jest

Lepp está pensado para prototipos y proyectos demostrativos. La configuracion del servidor debe ser lo más resumida posible y lo más sencillo de implementar, incluso si se sacrifica control sobre la caracteristica, ya que esto resta protagonismo al proyecto que el programador final desea llevar a cabo.

En esta librería debe concentrarse todo el caos arquitectónico que suele haber en proyectos de Express o Sockets.io (APIs en general), para que el programador final no tenga que verlo ni pensarlo.

Contribuir

Como leíste en mi guia, empezá forkeando y clonando el repositorio.

Estructura

Cuando abras tu editor favorito, vas a ver algo como

project/
├── src/
│   ├── server/ 
|   |   ├── App.ts
|   │   └── ...
│   │
│   ├── utils/
|   |   └── ...
│   |
│   └── Lepp.ts
│    
├── index.js
├── package.json
├── .gitignore
├── tsconfig.json
├── .eslintrc.json
└── ...

index.ts es el punto de entrada de la librería, ahí se exportan la clase Lepp, los decoradores y las extensiones, nada más.

package.json, .gitignore, tsconfig.json, .eslintrc.json, entre otros, son los archivos de configuración del entorno. Estos nos definen algunas reglas de estilo que hay que respetar.

src/Lepp.ts La clase principal, que abstrae cualquer implementación que hay en la librería, para que el programador final sepa claramente qué hace cada cosa. Debe estar incluso sobredocumentada, con ejemplos y todo. Por lo general los métodos delegan las tareas a otras clases.

src/server/* Acá se encuentra la configuración de express, con todos métodos que interactuan con la instancia de express.

src/utils/* Sí, todo lo que no sabés donde va, va en utils. Principalmente funciones, interfaces, y algoritmos auxiliares. Es un espacio más bien libre.

En todo el proyecto a lógica es la misma: Cada archivo exporta por defecto una clase o una función con el mismo nombre del archivo.
Evitá lo mas posible el uso de funciones individuales.

Primeros pasos

En la raiz del proyecto, ejecuta el comando npm i.
Crea una nueva rama.

Dentro de la carpeta src Crea un archivo Main.ts, que es ingnorado por git, y pega lo siguiente:

if(process.env.NODE_ENV === "development") require("dotenv").config();
import Lepp from "./Lepp";

class Main {
    public static main():void {
        const lepp = new Lepp(3000);

        lepp.use_helmet()
            .use_bodyparser()
            .use_morgan("tiny");

        lepp.use_default_routes();
        lepp.run();
    }
}

Main.main();

Este archivo es el punto de entrada de desarrollo.
Ejecuta npm run dev, e ingresa a http://localhost:3000/ para ver que todo funcione.

Para picar código, no olvides tener la extension eslint instalada en tu editor de código favorito.

Lee los issues, selecciona la tarea, y desarrolla la solución.

Estilo

Programar con estilo es clave.
De todas formas, más allá de eslint, sos libre de programar como más te guste.

Algunas buenas prácticas:

  • Define las variables y nombres de funciones en snake_case minúsculas.
  • Evita a toda costa el código ofuscado. Una linea, una instruccion.
  • Usa los JSDoc SIEMPRE
  • Una función/método, una accion.
  • Evita más de dos parámetros por función/método, sino se entiende que esa función hace demasiadas cosas.
  • Define los tipos de datos siempre, incluyendo los de retorno.
  • Colócale nombres descriptivos a las funciones. Asegúrate que éstas o hagan exactamente lo que dice su nombre, no importa si suenan ridículos o son muy extensos.

Más cosas

El contributing también se escribe a medida que surgen nuevas dudas.
Por favor, deja un issues con la etiqueta de question y pregunta lo que necesites saber.