ironhack-labs / irongenerator Goto Github PK

Missing prettier dependency. Should add it, bump package version and deploy.

• The route-guars.js file is missing additional extension for templating .ejs

  • Solution: add .ejs so we would have route-guars.js.ejs

• In advanced mode, whether we choose or not to use the 'use strict' mode, it comes by default with it.

  • Solution: remove the dependency so it adds use strict only when requested.

Should be investigated.

Behavior doesn't seem to be entirely consistent.

It might be related to having one of the following properties in the cookie options:

{
  // ...
  sameSite: 'lax',
  httpOnly: true,
  secure: process.env.NODE_ENV === 'production'
  // ...
}

Solution might involve setting the option "trust proxy" to true on the express app with app.set('trust proxy', true).

The relevant flags should be added to development scripts using nodemon to ensure that it is refreshed whenever there's a file change in the directory.

For example:

{
  // ...
  "scripts": "nodemon server.js -e js,json,hbs,scss"
  // ...
}

Add contribution guidelines to CODE-OF-CONDUCT.md. The most used open-source code of conduct is the one from Contributor Covenant (latest version 2.0); it can be found here.

Add github workflow to deploy to npm on release.

The package should be automatically published when there's a bump in the version.

A github action such as the following could be used for this.

The code in create-app.js is excessively verbose, doesn't adhere to DRY or SOLID principles.

Usage of the package might not be immediately clear from the information displayed in the README.md file.

Should add information regarding the possible options for bootstrapping process, explain the usage of "beginner"/"intermediate"/"advanced" configuration options, quick overview of what each option does, especially the options regarding authentication.

Include explanation on the requirements to run the bootstrapped app, compatible version of node, inclusion of environment variables.

There have been multiple relevant changes since the last publication of the package.

• Routes files should be named with: name.routes.js

  • should we name authentication routes:
    [ ] a) authentication.routes.js or
    [ ] b) auth.routes.js?

• Model files should be named with: name.model.js

  • should we name model routes:
    • a) Name.routes.js (User.model.js) or
    • b) name.routes.js (user.model.js)?

• Auth views should be

  • named:
  • a) login.hbs & signup.hbs
  • b) log-in.hbs & sign-up.hbs
  • separated into sub-folder: views > auth > login.hbs & signup.hbs:
  • a) yes
  • b) no

• Should user.hbs be

  • profile.hbs or
  • user-profile?

• Should middleware > route-guard.js be plural middleware > route-guards.js?

How should coding style guidelines be defined and enforced?

Should be refactored to be more understandable by newbies.

At the moment, the server tries to connect to MongoDB without informing the user beforehand. If MongoDB is not running, it takes 30s for the error message to be displayed.

A message should be logged using the debug package, in order to ensure that the user is aware that the server is starting up, before connecting to MongoDB.

Add contribution guidelines to CONTRIBUTING.md. A good starting point would be this boilerplate.

Current contribution guidelines are available here.

Rest API Scaffolding includes middleware for serving favicon and routes/index it tries to render a view.

We should decide on the rules to publish ironmaker, and create contribution guidelines to match those principles.

This article provides interesting insights regarding this issue.

The folder structure needs to be standardized. The proposal can be found on the miro working area.

1. Option: Beginner

├── app.js
├── package.json
├── public
│   ├── images
│   │   └── favicon.ico
│   ├── scripts
│   │   └── script.js
│   └── styles
│       └── style.css
├── routes
│   └── index.js ===> should this be index.routes.js?
├── server.js
└── views
    ├── error.html
    ├── index.html
    └── user.html

2. Option: Medium (shall it be renamed to Intermediate?)

• When actually do we use this option during the course?

├── app.js
├── models
│   └── user.js ===> to be renamed to user.model.js (or: User.model.js?)
├── package.json
├── public
│   ├── images
│   │   └── favicon.ico
│   ├── scripts
│   │   └── script.js
│   └── styles
│       └── style.css
├── routes
│   └── index.js ===> should this be index.routes.js?
├── server.js
└── views
    ├── error.html ===> do we need html files still?
    ├── index.html
    └── user.html

3.1) Option: Advanced -> MVC (no authentication)

├── app.js
├── models
│   └── user.js ===> to be renamed to user.model.js (or: User.model.js?)cd adv
├── package.json
├── public
│   ├── images
│   │   └── favicon.ico
│   ├── scripts
│   │   └── script.js
│   └── styles
│       └── style.css
├── routes
│   └── index.js ===> should this be index.routes.js?
├── server.js
└── views
    ├── error.hbs
    ├── index.hbs
    ├── layout.hbs
    ├── private.hbs
    ├── sign-in.hbs ===> should this be login.hbs or log-in.hbs? should we have subfolder for auth (signup and login) views?
    ├── sign-up.hbs
    └── user.hbs ===> should this be profile.hbs?

3.2) Option: Advanced -> MVC -> with AUTH -> basic session and cookies

├── app.js
├── middleware
│   ├── basic-authentication-deserializer.js
│   ├── bind-user-to-view-locals.js
│   └── route-guard.js ===> should this be plural - guards?
├── models
│   └── user.js ===> the same as above - user.model.js or User.model.js?
├── package.json
├── public
│   ├── images
│   │   └── favicon.ico
│   ├── scripts
│   │   └── script.js
│   └── styles
│       └── style.css
├── routes
│   ├── authentication.js ===> should this be authentication.routes.js? or auth.routes.js?
│   └── index.js ===> should this be index.routes.js?
├── server.js
└── views
    ├── error.hbs
    ├── index.hbs
    ├── layout.hbs
    ├── private.hbs
    ├── sign-in.hbs ===> the same as above? naming and subfolder?
    ├── sign-up.hbs
    └── user.hbs ===> should this be profile.hbs?

3.3) Option: Advanced -> MVC -> with AUTH -> passport

├── app.js
├── middleware
│   ├── bind-user-to-view-locals.js
│   └── route-guard.js ===> the same as above, should this be guards?
├── models
│   └── user.js ===> user.model.js or User.model.js?
├── package.json
├── passport-configuration.js ===> should this be in middlewares or configs? should we have 4 separate files for all 4 strategies (local, twitter, github, facebook)?
├── public
│   ├── images
│   │   └── favicon.ico
│   ├── scripts
│   │   └── script.js
│   └── styles
│       └── style.css
├── routes
│   ├── authentication.js ===> naming with .routes.js
│   └── index.js ===> naming with .routes.js
├── server.js
└── views
    ├── error.hbs
    ├── index.hbs
    ├── layout.hbs
    ├── private.hbs
    ├── sign-in.hbs ===> the same as above - login or log-in? should we have auth-views subfolder?
    ├── sign-up.hbs
    └── user.hbs

3.4) Option: Advanced -> REST API -> no AUTH

├── app.js
├── models
│   └── user.js ===> naming with .model.js?
├── package.json
├── public
│   └── images
│       └── favicon.ico
├── routes
│   └── index.js ===> naming with .routes.js?
└── server.js

3.5) Option: Advanced -> REST API -> with AUTH -> basic session and cookies

├── app.js
├── middleware
│   ├── basic-authentication-deserializer.js 
│   ├── bind-user-to-view-locals.js
│   └── route-guard.js
├── models
│   └── user.js
├── package.json
├── public
│   └── images
│       └── favicon.ico
├── routes
│   ├── authentication.js
│   └── index.js
└── server.js

3.5) Option: Advanced -> REST API -> with AUTH -> passport

├── app.js
├── middleware
│   ├── bind-user-to-view-locals.js
│   └── route-guard.js ===> guards?
├── models
│   └── user.js ===> user.model.js or User.model.js
├── package.json
├── passport-configuration.js ===> configs and subfolders and files*
├── public
│   └── images
│       └── favicon.ico
├── routes
│   ├── authentication.js ===> authentication.routes.js or auth.routes.js
│   └── index.js ==> index.routes.js
└── server.js

• Linking here an issue related to passport files and folders structure:

• Linking here an issue related to pointed naming conventions: issue #9

We should add automated tests that check if the app is being correctly bootstrapped with the multiple possible configurations.

This will ensure that any changes or enhancements will not break the bootstrapping process.