generator-confit/lib/projectType/node/nodeResources.yml

Yeoman generator for creating the development process, tools and a sample project for current-generation web applications

# App configuration
app:
  subGenerators:
    - confit:paths
    - confit:buildJS
    - confit:entryPoint
    - confit:testUnit
    - confit:verify
    - confit:documentation
    - confit:release
    - confit:sampleApp
    - confit:zzfinish

  packages:
    - <<: *pkg_npm-run-all
    - <<: *pkg_rimraf
    - <<: *pkg_cross-env

  tasks:
    - name: start
      tasks: ['npm run dev']
      description: Alias for `npm run dev` task
      features:

    - name: dev
      tasks: ['cross-env NODE_ENV=development npm run verify:watch']    # Later, add build task if required
      description: Run project in development mode (verify code, and re-verify when code is changed)
      features:

    - name: build
      tasks: ['cross-env NODE_ENV=production npm run clean:prod']   # Later on, we may need to add a build-task here
      description: Generate production build into <%= link(paths.output.prodDir) %> folder
      features:

    - name: clean:prod
      tasks: ['rimraf <%= paths.output.prodDir %>']
      description:
      features:

# Frameworks are used by multiple generators
frameworks:
  '':
    ES6:
      entryPointFileName: <%- paths.input.srcDir + resources.sampleApp.demoDir %>index.js
    frameworkPackages: {}
    frameworkTestPackages: {}


buildJS:
  defaults:
    sourceFormat: ES6
    outputFormat: ES6
    # No default framework

  showVendorScripts: false

  sourceFormat:
    ES6:
      ext: ['js']

  outputFormat:
    - ES6


entryPoint:
  defaults:
    entryPoint:
      ES6: index.js
      TypeScript: index.ts

  readme:
    extensionPoint:
      entryPoint: >
        The `entryPoint.entryPoints` string in <%= link(configFile) %> is designed to be edited manually.
        It represents the starting-point(s) of the application (like a `main()` function). A NodeJS application has
        one entry point. E.g. `src/index.js`


# Path Defaults
paths:
  prompts:
    - name: input.srcDir
      message: Path to SOURCE directory (relative to the current directory)

    - name: input.unitTestDir
      message: Path to UNIT TEST directory (relative to the current directory)

    - name: output.prodDir
      message: Path to BUILD directory (relative to the current directory)

    - name: output.reportDir
      message: Path to TEST REPORTS directory (relative to the current directory)

    - name: config.configDir
      message: Path to CONFIG directory (relative to the current directory)


  defaults:
    input:
      srcDir: src/
      unitTestDir: test/
    output:
      prodDir: dist/
      reportDir: reports/
    config:
      configDir: config/

  pathsToGenerate: []

# README section for the template tags that will appear inside the README.md template
readme:
  RM_DIR_STRUCTURE: |
    ## Directory Structure

    Code is organised into modules which contain one-or-more components. This a great way to ensure maintainable code by encapsulation of behavior logic. A component is basically a self contained app usually in a single file or a folder with each concern as a file: style, template, specs, e2e, and component class. Here's how it looks:
    ```<% var maxDirLen = 30; %>
    <%- pkg.name %>/
     ├──<%- rpad(paths.config.configDir, maxDirLen)%>* configuration files live here (e.g. eslint, verify, testUnit)
     │
     ├──<%- rpad(paths.input.srcDir, maxDirLen) %>* source code files should be here
     │
     ├──<%- rpad(paths.output.prodDir, maxDirLen) %>* production-build code should live here
     │
     ├──<%- rpad(paths.output.reportDir, maxDirLen) %>* test reports appear here
     │
     ├──<%- rpad(paths.input.unitTestDir, maxDirLen) %>* unit test specifications live here<% if (documentation.generateDocs) { %>
     │
     ├──<%- rpad(documentation.srcDir, maxDirLen) %>* source/content for the documentation website goes here
     ├──<%- rpad(documentation.outputDir, maxDirLen) %>* the documentation website is generated here<% } %>
     │
     ├──<%- rpad(configFile, maxDirLen) %>* the project config file generated by 'yo confit'
     ├──<%- rpad('CONTRIBUTING.md', maxDirLen) %>* how to contribute to the project
     ├──<%- rpad('README.md', maxDirLen) %>* this file
     └──<%- rpad('package.json', maxDirLen) %>* NPM package description file
    ```


  RM_NEXT_STEPS: |
    ## *Next Steps to Setup your Project*

        Remove this section once you are comfortable updating your project.

    - [ ] Update [package.json](package.json) with a nice description, then run `yo confit --skip-install --skip-run` and see the README.md file is updated
    - [ ] Add a new **dependency** to your project:
      - For a **source-code** dependency:
        1. `npm i {nodeModule} --save`
      - For a **development** dependency:
        1. `npm i {nodeModule} --save-dev`
      - For a **test** dependency:
        1. `npm i {nodeModule} --save`
    <% if (release.useSemantic) { %>- [ ] Complete the installation of the **semantic release** tool:
      1. Make sure you have:
        - a GitHub login
        - an NPM login
        - a TravisCI login (though you can still proceed if you use a different CI tool)
      1. Run `semantic-release-cli setup` to complete the installation
    <% } -%>
    <% if (release.checkCodeCoverage && app.repositoryType === 'GitHub') { %>- [ ] Install code coverage:
      1. Make sure you have:
        - a TravisCI login (though you can still proceed if you use a different CI tool)
        - a [Coveralls](https://coveralls.io) account
      1. Push your code to GitHub.
      1. Login to [Coveralls](https://coveralls.io/).
      1. Press Add Repo. You may need to Sync your GitHub repos to see your new repo in the list.
      1. Select the repo and you will see a "Set Up Coveralls" page. Note the `repo_token` value.
      1. Login to [Travis CI](https://travis-ci.org/).
      1. Edit the settings for this repo (More Settings > Settings).
      1. In the Environment Variables section, create a new envrionment variable called `COVERALLS_REPO_TOKEN` and set its value to the *repo_token* value shown on the "Set Up Coveralls" page, and press "Add".
      1. Push another commit to GitHub and you should get a coverage report now!
    <% } -%>
    - [ ] Run `npm test` to execute the tests and see the test coverage
    <% if (release.commitMessageFormat === 'Conventional') { %>- [ ] Run `git cz` to commit changes with a conventional commit message
    <% } -%>


sampleApp:
  demoDir: demo/   # This is ALWAYS a subdirectory of the srcDir directory

testUnit:
  defaults:
    testFramework: mocha

  testFrameworks:
    - mocha

verify:
  verifyTasks: ['verify:js']

  configModules:
    - packages:   # Common tools
        - <<: *pkg_eslint
        - <<: *pkg_eslint-plugin-node
        - <<: *pkg_eslint-friendly-formatter
      templateFiles:
        - src: eslintignore.yml.tpl
          dest: .eslintignore
          overwrite: true
        - src: .eslintrc.js.tpl
          dest: <%= paths.config.configDir + resources.verify.configSubDir %>.eslintrc.js
          overwrite: true

    - condition: <%- verify.jsCodingStandard === 'AirBnB' %>
      packages:
        - <<: *pkg_eslint-config-airbnb
        - <<: *pkg_eslint-plugin-import
        - <<: *pkg_eslint-plugin-react
        - <<: *pkg_eslint-plugin-jsx-a11y

    - condition: <%- verify.jsCodingStandard === 'Google' %>
      packages:
        - <<: *pkg_eslint-config-google

    - condition: <%- verify.jsCodingStandard === 'StandardJS' %>
      packages:
        - <<: *pkg_eslint-config-standard
        - <<: *pkg_eslint-plugin-standard
        - <<: *pkg_eslint-plugin-promise

    - condition: <%- verify.jsCodingStandard === 'TypeScript' %>
      packages:
        - <<: *pkg_tslint
      templateFiles:
        - src: tslint.json
          dest: <%= paths.config.configDir + resources.verify.configSubDir %>tslint.json

zzfinish: {}    # For node projects, don't 'npm start' the project