moleculerjs / moleculer-cli

:herb: Command line tool for Moleculer
http://moleculer.services/docs/moleculer-cli.html
MIT License
48 stars 28 forks source link

Remove hardcoded Metalsmith template directory #22

Closed ccampanale closed 5 years ago

ccampanale commented 5 years ago

This PR moves the hardcoded "template" directory name to values.templateDir to allow for customization of this default value via meta.js when using the moleculer-cli to init new projects.

Use case: Allow for multiple template directories to be defined in a single template repository where the type of project being generated is the same but the files may be vastly different. (For example, polyglot service generation.)

Background: I have a template repository for a specific type of microservice project with defaults and configurations handled by meta.js. I've recently re-written the service entirely in TypeScript and want to provide it as an optional template in the same repository, as it is after all, the same service type just in a different language. While a separate repository altogether would be fine, I would prefer to keep all of my "apples" together and separate from my "oranges". In essence, though written in a different language, the base service generated is still the same fundamentally. This change would allow the developer to add options to their meta.js which could be used to determine which internal template directory to provide to metalsmith.

Example:

"use strict";

module.exports = function(values) {
  return {
    questions: [
      {
        type: "list",
        name: "templateDir",
        message: "Select target language",
        choices: [
          { name: "Javascript", value: "template" },
          { name: "TypeScript", value: "template-ts" }
        ],
        default: "Javascript"
      }
    ]
  };
};

Ultimately, I think the idea here is the recognition of commonality between templates. While you could argue that an entirely separate repository could be used to achieve the same goal, I would argue that would introduce unnecessary overhead that could be avoided by maintain the same two concepts in a single repository.

I've tested this locally and it works fine however I think it's worth noting that neither the original solution nor this change do any sort of validation that the "template" directory (or dynamically set variation thereof) actually exists and may be desired.

Let me know what you think and if you have any questions.

icebob commented 5 years ago

Good job, I think it is a good feature. Thank you!