Classifying Trailpacks

[nogtini]

As it stands for prototyping, current placeholder trailpacks were separated into the following categories:

TaskRunner
FrontEnd
Router
Auth

The current actual list of Trailpacks consists of:

Knex
Footprints
Webserver
Hapi
Repl
Router
Core
Waterline
Bootstrap
React
Express
Mongoose
Autoreload
Sequelize
Bookshelf
Sails
GraphQL
Realtime
DataStore
Swagger
Webpack
Typescript
Permissions
Auth
Koa
Fixtures
Microservices

We need to organize these into categories such that they can accounted for with the GUI. For example, I'm considering having "core" trailpacks like core, auth, repl, etc. into a new category called "Core". All Trailspacks should be able to fit into a descriptive category.

Open discussion is welcome.

[weyj4]

That works for me. As it stands, the only 'Core' subcategory that has working trailpacks is the Servers. What do you think some of the other categories would be?

We could have noncore builds like trailpack-react, which would be more preconfigured (i.e. it combines react and webpack). This is related to our general trailpack discussion.

[nogtini]

We'd ideally want to have independent categories, not relational. For instance, trailpack-react would fall under Front-End rather than Non-Core.

[jaumard]

Here is some ideas for categories :

Dev : repl, autoreload, fixtures
Utils: swagger, realtime, footprint, bootstrap, auth, permissions, microservices
Database: waterline, mongoose, sequelize, bookshelf, knex, graphQL
Webserver: express, hapi, koa, sails
Front: react, angular
TaskRunner: gulp, webpack, typescript

Here is the trailpack I will not show on trails mix :
DataStore : because only used by Databases trailpacks
WebServer: same as Datastore but for webservers
Core : there is actually no case were we don't install it
Router : for me when a web server is choose router have to be included by default

[weyj4]

Ah, ok. The complication there is that trailpack-react includes its own webpack config. That's something else we can talk about with regard to that individual trailpack.

[jaumard]

We also can add a Category Other or Community with a npm search like this https://registry.npmjs.org/-/_view/byKeyword?startkey=[%22trailpack%22]&endkey=[%22trailpack%22,{}]&group_level=3
To have community trailpacks included in TrailsMix :)

[tjwebb]

Proposal

Each trailpack should declare which category it is in. Trailpacks cannot be in more than one category; although, you may install multiple trailpacks in a single category in your trails app.

1. abstract

Abstract trailpacks are those which other trailpacks themselves must require and inherit from. These should never be loaded directly. I don't think these need to be listed on trailmix.

2. system

These are trailpacks that must be required for any of this categorization to make any sense. Currently, these could include core and router. These also can be omitted from trailmix. These will be included in any default build, and are "opt-out".

3. server

Web servers, basically. express, hapi, koa, etc. Anything that handles requests over http. They extend trailpack-webserver

4. datastore

Packs that help you connect to datastores. They extend trailpack-datastore.

5. dev

Anything you'd normally put in devDependencies should go in here. This means that things like webpack and gulp, which could be used to produce production builds and so forth, will be in this category. It also means that few, if any, trailpacks should actually rely on the existence of any pack in this category during runtime. repl will also go in here.

6. util/misc/extra

These trailpacks augment functionality in some trailpack(s) from the previous categories. Examples are realtime (which will augment a webserver), and footprint (which augments a webserver and a datastore). I also think that fixtures and sails belong in this category.

[jaumard]

@tjwebb
3.server and 4.datastore must allow only one trailpack, and multiple for other categories.

not agree with 5.dev because if it's devDependencies that's mean in production they're not installed npm install --production even if a trailpack is not require in production it have to be installed or the server will crash because the trailpack is require under main.js.
You can put trailpack on devDependencies only if they are used only in tests.
But ok for the name of this category :) just not the explanation

[tjwebb]

You can put trailpack on devDependencies only if they are used only in tests.

Not necessarily; I include plenty of devDependencies like webpack, grunt, etc, that I use as build tools. But you're right that many of these are configurable to also be useful in production.

3.server and 4.datastore must allow only one trailpack, and multiple for other categories.

Yea, that's basically right. I don't see a strong need to enforce this programmatically, but I think if you feel like you need to use multiple web servers or datastores, you likely need to break apart your application into separate modules.

[tjwebb]

Ok how about this:

Rename dev to tools, and util/misc/extra to extensions to more accurately convey their purpose. And we clarify that servers and datastores should be treated as singletons.

5. tools

These can be dev tools, build tools, monitoring tools, whatever. Examples are repl, webpack, autoreload, and similar.

6. extensions

These trailpacks augment or extend functionality in some trailpack(s) in the other categories; therefore, the trailpacks in this category may depend directly on other specific trailpacks in order to function. Examples are realtime (which will augment a webserver), footprint (which augments a webserver and a datastore), sails (which augments the webserver, sort of.), fixtures (datastore).

[tjwebb]

And only things in categories 3,4,5,6 are worth searching for in trailmix.

[jaumard]

@tjwebb I don't see why user need multiple web server but I see some case when you need for example mysql database and a mongoDB one so if you don't use Waterline you need trailpack-knex and trailpack-mongoose for example. But it will simply not working because ORM is set into app.orm and one will be override the other ^^ so for now it's better if we can choose only one.

Agree for categories names and for only searching into 3,4,5,6 (and yes abstract shouldn't be under trailsmix ui).