Nodebestpractices: CLI to generate boilerplate code following the best practices

Created on 3 Jul 2019  ·  10Comments  ·  Source: goldbergyoni/nodebestpractices

Hello everyone, i was thinking about create a template following the recommendations presents here in community. What do you think? Or everyone already have your own templates for new projects?

stale

Most helpful comment

I think it would be a great to have a few project templates, maybe very specific, that show how to implement a limited set of these best practices.

Even if such templates don't cover all best practices it would more helpful than not having them at all

All 10 comments

@VilsonJrCorrea

I'm not sure that it's possible as a boilerplate. If you just need a blog or just a chat, then you will probably follow some more dense and complete templates based on a platform.

The BP are collection of recipes for all occasions. This is when you can always apply them, not only for templating or scaffolding. Therefore, all boilerplates must be created according to these rules. Well, or may use them.

@oshliaer @VilsonJrCorrea

Interesting. Let's think together what this CLI can generate for example and what it can't?

It can

  1. Create all the project obvious artifacts (.gitignore, .editorconfig, semantic commit + many others)
  2. Rich eslint setup including additional important rules
  3. Multiple folder layers - entry points (API, CLI), domain, data-access. We can include within each layer one example of a route, 3 basic data-access operations
  4. Supporting libraries - separated generic utils like logger, config reader, etc
  5. Error handling flow example including a small lib that defines a custom error and handling
  6. Integration & unit tests example including CI file for the popular providers
  7. Semantic log writing that includes a unique transaction id within each request
  8. Many others
  9. Snippets for vscode

What is not possible

  1. ?

It can't

  1. Provide a system against leaks. We can not take in mind all the details of connecting to interfaces or databases without a unified platform implementation.
  2. Provide a variety of applications. It can be separate for a blog, chat, basket, but not for the whole factory of applications.
  3. Provide flexible a code base. Very often the standard code is not a panacea. Can we guarantee SOLID?

Again. I'm bad in English. My goal is to explain that automated builds are not bad. But this is not always possible. Especially, when we don't have clear rules and we see only very well thought-out professional recommendations (aka best practices).

I think it would be a great to have a few project templates, maybe very specific, that show how to implement a limited set of these best practices.

Even if such templates don't cover all best practices it would more helpful than not having them at all

Just my two cents, things can be separated into two categories :

  • Personal Preferences ( out of choices probably ) - this includes linter, editorconfig, folder structure, logger, and of many more that are common for all projects.
  • Project Nature - @goldbergyoni has defined it as layers, which is a great way to describe modularisation ( with shared parts ) of big projects with many entry points, but also one could be building only some of those. Here it is the real challenge to build a CLI which will let you start with something, maintain it, and grow with it.

Maybe as a start we should look at similar projects and see what we can take from there and if it's possible to design something that is easy to use and assists you instead of tying you into it.

@oshliaer I agree that such boilerplates can give only the ~70% of quality steps one should implement in a project, at some point there must be contextual & human judgment. But still, the 70% is critical and many get these wrong. The most reputable architectures don't assume anything about a project (besides being big enough) and still are counted as best practice.

As an example, we can't guarantee SOLID but we can include layers which pushes toward SoC.

My point is that we can't give all but what we can is valuable enough. Can we?

Maybe as a start we should look at similar projects and see what we can take from there and if it's possible to design something that is easy to use and assists you instead of tying you into it.

Good idea, do you have some examples?

  • Personal Preferences ( out of choices probably ) - this includes linter, editorconfig, folder structure, logger, and of many more that are common for all projects

I like this, so basically the user being presented with a menu:

  • Default
  • Cherrypick

Should she chose cherrypick then we present opt-in questions:

  • Do you want to have example tests?
  • Shall we include a basic linter?
  • Shall we enrich these linters with multiple advanced rules that we recommend?
  • And so on with things like semantic release, request context (i.e. transaction id), monitoring, etc

Is this basically the idea?

I think it would be a great to have a few project templates

Interesting, can we clarify what is a template? which developer UX do you envision (e.g. what does the CLI ask, what does it do, etc)?

My point is that we can't give all but what we can is valuable enough. Can we?

Totally agree!
Yes, we can =)

Hello there! 👋
This issue has gone silent. Eerily silent. ⏳
We currently close issues after 100 days of inactivity. It has been 90 days since the last update here.
If needed, you can keep it open by replying here.
Thanks for being a part of the Node.js Best Practices community! 💚

Was this page helpful?
0 / 5 - 0 ratings