A few remakes to note

[j-san]

Just tried the last keystone with yo and it rocks ! But I have a few remakes to note:

• User model: What append if I remove it ? It could be great if keystone create a default models if it is not declared.
• flash message middleware: What append if I remove it ? It can be a database issue if messages are pushed on session but never popped ? A default behavior with the ability to customize it can be useful.
• Wath about Yo sub-generator for usual module like blog, model, grunt, glup, test,... As I do not have to decide at the beginning what I need. for instance yo keystone:make-test could generate a Makfile with dependencies to jshint, mocha, blacket, and a simple tests for homepage with supertest in addition of my existing project.
• Is dotenv a dev dependency ?
• I usually use supervisor for dev, maybe can be useful with a npm start config ?
• For tests I need to run keystone in silence mode but can not find option.
• If a model filed is required it must be initial or I can't create documents.

[JedWatson]

Hi @j-san, thanks for the feedback!

Some responses:

User Model

The User model is not necessarily required; without it you can actually run Keystone with no auth (although it would be an extremely rare scenario where you would do this!)

The reason it's not automatically created is that we want Keystone to be useful out of the box, but totally flexible - so you can change anything you need to without abandoning the rest of the framework. We have sites where there are multiple User models (one for Admins, plus one or more for user accounts) and others where it's called something different for legacy reasons (e.g. Profiles).

That said, this may be something we make more automatic in the future - so you could "Add user model" through a plugin or function instead of creating it yourself.

Flash Messages

There's express middleware that Keystone includes to support this, and which Keystone uses for the Admin UI. But I think you are talking about the templates included in the yo keystone default? If you don't want to use it in your front-end that's fine, just remove it and don't use the functionality (or replace it with something else). It's just there to be useful if you want it.

Some features (like the UpdateHandler) specifically support it to make validation messages trivial to implement, but this is opt-in and you can easily replace it with your own solution.

Sub Generators

This is absolutely on the list, just haven't gotten around to it yet. There are a couple of issues in the generator repo, but a lot more that can be done.

dotenv

This is actually a normal dependency bundled with the yo keystone templates, you need it whether there is a .env file or not because it is required. You're free to remove it in your project though, Keystone itself doesn't use it at all.

Many of the settings can be set either with environment variables, or within the project code itself. For some closed-source projects it may be easier to keep account details in the code, but generally best practice would be to use environment variables.

Supervisor

Nodemon is also popular, I think it's best not to assume the presence of either in the default npm start setting, or it would create errors for people who didn't have the chosen one installed.

We could offer to include it in the generator, but I also think every question adds complexity, especially for people new to node. Not sure the best way to make this a good experience. Maybe we could add a note to the getting started..?

RE: tests, what do you mean by silence mode?

Hope this clears things up a bit!

[j-san]

Thank you Jed :)

For Supervisor I always install it locally, for instance with Nodemon: In my package.json

  "scripts": {
    ...
    "start": "node_modules/.bin/nodemon keystone.js",
  },
  "devDependencies": {
    ...
    "nodemon": "*"
  }

and i run with npm start

By silence mode i meen i need to run a part of the server without any log output to have a clean and readable output of tests results. But also for html reports, in Mocha i need to generate report with this command: NODE_ENV=test node_modules/.bin/mocha --reporter html-cov > results/coverage.html. The output of Mocha is redirect into a file but also http logs and keystone start message.

In general, i feel important to choose the logs format, colorized or not. Ability to choose between dev logs, server logs or no logs should be a good deal, dev logs must be readable, server logs should contains timestamp, ip and some defined http header. In some case error logs should be send by mail. Maybe this options exists with express.

[j-san]

I opened a pull request for initial field #306 ;)

[morenoh149]

closed due to - not an issue