# Common configuration regardless of project type

# Globals
rootGeneratorName: generator-confit

# App configuration
app:
  defaults:
    projectType: browser
    license: UNLICENSED
    publicRepository: true

  repositoryTypes:
    - GitHub
    - BitBucket
    - Other

  projectTypeList:
    - value: browser
      name: Browser - web apps, websites for browsers
    - value: node
      name: NodeJS - node modules, server applications

  templateFiles:
    - src: editorconfig
      dest: .editorconfig
      overwrite: false
    - src: gitignore
      dest: .gitignore
      overwrite: false

  licenses:
    popular:    # Taken from https://opensource.org/licenses/category
      - UNLICENSED
      - Apache-2.0
      - BSD-2-Clause
      - BSD-3-Clause
      - GPL
      - LGPL
      - MIT
      - MPL-2.0
      - CDDL-1.0
      - EPL-1.0

    noLicenseFile:
      - UNLICENSED

    templateFiles:
      - src: LICENSE.txt
        dest: LICENSE
        overwrite: false    # We only want to generate this file once. To change it, delete the file then re-run confit

  packageJsonConfig:
    - license: <%- app.license %>

  configModules:
    - condition: <%- app.publicRepository %>
      readmeBadges:
        - name: NPM Version
          image: https://img.shields.io/npm/v/<%- pkg.name %>.svg?style=flat-square
          url: http://npm.im/<%- pkg.name %>
          priority: 1
        - name: Dependencies status
          image: https://david-dm.org/<%- repoConfig.repository %>/status.svg?theme=shields.io
          url: https://david-dm.org/<%- repoConfig.repository %>#info=dependencies
          priority: 40
        - name: Dev-dependencies status
          image: https://david-dm.org/<%- repoConfig.repository %>/dev-status.svg?theme=shields.io
          url: https://david-dm.org/<%- repoConfig.repository %>#info=devDependencies
          priority: 41


documentation:
  GITHUB_PUBLISH_METHOD: GitHub   # This is a special documentation method, so this global is handy to refer to it in code
  configSubDir: docs/

  defaults:
    generateDocs: true
    srcDir: docs/
    outputDir: webdocs/
    publishMethod: manual
    createSampleDocs: true    # But we should ask the question everytime, until the user says "false"

  publishMethods:
    - value: GitHub
      name: GitHub
    - value: cloud
      name: Publish to the cloud
    - value: manual
      name: Publish manually

  # There are no packages/templates to install globally, so no need to add a condition: here


confitLib:
  configSubDir: confit/


# README section for the template tags that will appear inside the README.md template
# All of these properties are COMMON across all project types
readme:
  RM_HEADING: '# <%- pkg.name %>'
  RM_DESCRIPTION: '> <%- pkg.description %>'
  RM_INSTALL: |
    ## Install

        npm install <%- pkg.name %>

  RM_BADGES: |
    <% objectValues(readme.badges).sort(function(a, b) { return a.priority > b.priority}).forEach(function(badge) {
    %>[![<%- badge.name -%>](<%- badge.image -%>)](<%- badge.url -%>)
    <% }); -%>

  RM_CONTRIBUTING: |
    ## Contributing

    See [CONTRIBUTING.md](CONTRIBUTING.md).

  RM_LICENSE: |
    ## License

    <% if (!app.license || app.license === 'UNLICENSED') { %>This software does not have a license.
    <% } else { -%>This software is licensed under the <%- app.license %> Licence. See [LICENSE](LICENSE).<% } -%>

  CN_HEADING: |
    # Contributing

    Welcome! This document explains how you can contribute to making **<%- pkg.name %>** even better.

  CN_GETTING_STARTED: |
    # Getting Started

    ## Installation

    ```
    git clone <this repo>
    <% globalPackages.forEach(function(pkg) {%>npm install -g <%- pkg.name %>
    <% }); %>npm install
    ```

  CN_GITFLOW_PROCESS: |
    # GitFlow Development Process

    This project uses the [GitHub Flow](https://guides.github.com/introduction/flow/index.html) workflow.

    ## Create a branch
    When you're working on a project, you're going to have a bunch of different features or ideas in progress at any given time – some of which are ready to go, and others which are not. Branching exists to help you manage this workflow.

    When you create a branch in your project, you're creating an environment where you can try out new ideas. Changes you make on a branch don't affect the `master` branch, so you're free to experiment and commit changes, safe in the knowledge that your branch won't be merged until it's ready to be reviewed by someone you're collaborating with.

    ###ProTip

    Branching is a core concept in Git, and the entire GitHub Flow is based upon it. There's only one rule: anything in the `master` branch is always deployable.

    Because of this, it's extremely important that your new branch is created off of `master` when working on a feature or a fix. Your branch name should be descriptive (e.g., `refactor-authentication`, `user-content-cache-key`, `make-retina-avatars`), so that others can see what is being worked on.

    ## Add commits
    Once your branch has been created, it's time to start making changes. Whenever you add, edit, or delete a file, you're making a commit, and adding them to your branch. This process of adding commits keeps track of your progress as you work on a feature branch.

    Commits also create a transparent history of your work that others can follow to understand what you've done and why. Each commit has an associated commit message, which is a description explaining why a particular change was made. Furthermore, each commit is considered a separate unit of change. This lets you roll back changes if a bug is found, or if you decide to head in a different direction.

    ###ProTip

    Commit messages are important, especially since Git tracks your changes and then displays them as commits once they're pushed to the server. By writing clear commit messages, you can make it easier for other people to follow along and provide feedback.

    ## Open a pull request

    Pull Requests initiate discussion about your commits. Because they're tightly integrated with the underlying Git repository, anyone can see exactly what changes would be merged if they accept your request.

    You can open a Pull Request at any point during the development process: when you have little or no code but want to share some screenshots or general ideas, when you're stuck and need help or advice, or when you're ready for someone to review your work. By using GitHub's @mention system in your Pull Request message, you can ask for feedback from specific people or teams, whether they're down the hall or ten time zones away.

    ###ProTip

    Pull Requests are useful for contributing to open source projects and for managing changes to shared repositories. If you're using a Fork & Pull Model, Pull Requests provide a way to notify project maintainers about the changes you'd like them to consider. If you're using a Shared Repository Model, Pull Requests help start code review and conversation about proposed changes before they're merged into the `master` branch.

    ## Discuss and review your code
    Once a Pull Request has been opened, the person or team reviewing your changes may have questions or comments. Perhaps the coding style doesn't match project guidelines, the change is missing unit tests, or maybe everything looks great and props are in order. Pull Requests are designed to encourage and capture this type of conversation.

    You can also continue to push to your branch in light of discussion and feedback about your commits. If someone comments that you forgot to do something or if there is a bug in the code, you can fix it in your branch and push up the change. GitHub will show your new commits and any additional feedback you may receive in the unified Pull Request view.

    ###ProTip

    Pull Request comments are written in Markdown, so you can embed images and emoji, use pre-formatted text blocks, and other lightweight formatting.

    ## Merge to `master`

    Once your PR has passed any the integration tests and received approval to merge, it is time to merge your code into the `master` branch.

    Once merged, Pull Requests preserve a record of the historical changes to your code. Because they're searchable, they let anyone go back in time to understand why and how a decision was made.

    ###ProTip

    By incorporating certain keywords into the text of your Pull Request, you can associate issues with code. When your Pull Request is merged, the related issues are also closed. For example, entering the phrase Closes #32 would close issue number 32 in the repository. For more information, check out our help article.


  CN_BUILD_TASKS: |
    ## Build Tasks

    Command | Description
    :------ | :----------
    <% if (readme.buildTask) { objectValues(readme.buildTask.app).concat(objectValues(readme.buildTask.build), objectValues(readme.buildTask.buildBrowser)).forEach(function(value) {
    %><pre><%- value.command %></pre> | <%- value.description %><%
      if (value.features && value.features.length) {
        %><ul><% value.features.forEach(function(feature){%><li><%- feature %></li><%}) %></ul><%
      } %>
    <% });}; %>


  CN_COMMIT_TASKS: |
    ## Commit Tasks

    Command | Description
    :------ | :----------
    <pre>git status</pre> | Lists the current branch and the status of changed files
    <pre>git log</pre> | Displays the commit log (press Q to quit viewing)
    <pre>git add .</pre> | Stages all modified & untracked files, ready to be committed
    <% if (readme.buildTask) { objectValues(readme.buildTask.commit).forEach(function(value) {
    %><pre><%- value.command %></pre> | <%- value.description %><%
      if (value.features && value.features.length) {
        %><ul><% value.features.forEach(function(feature){%><li><%- feature %></li><%}) %></ul><%
      } %>
    <% });}; -%>
    <pre>git push</pre> | Push local repository changes to remote repository


  CN_DOCUMENTATION_TASKS: |
    <% if (documentation.generateDocs) { %>## Documentation Tasks

    Command | Description
    :------ | :----------
    <% if (readme.buildTask) { objectValues(readme.buildTask.documentation).forEach(function(value) {
    %><pre><%- value.command %></pre> | <%- value.description %><%
      if (value.features && value.features.length) {
        %><ul><% value.features.forEach(function(feature){%><li><%- feature %></li><%}) %></ul><%
      } %>
    <% });};
    } %>

  CN_RELEASE_TASKS: |
    ## Release Tasks

    Command | Description
    :------ | :----------
    <% if (readme.buildTask) { objectValues(readme.buildTask.release).forEach(function(value) {
    %><pre><%- value.command %></pre> | <%- value.description %><%
      if (value.features && value.features.length) {
        %><ul><% value.features.forEach(function(feature){%><li><%- feature %></li><%}) %></ul><%
      } %>
    <% });}; %>

  CN_TEST_TASKS: |
    ## Test Tasks

    Command | Description
    :------ | :----------
    <% if (readme.buildTask) { objectValues(readme.buildTask.testUnit).concat(objectValues(readme.buildTask.testSystem), objectValues(readme.buildTask.testVisualRegression)).forEach(function(value) {
    %><pre><%- value.command %></pre> | <%- value.description %><%
      if (value.features && value.features.length) {
        %><ul><% value.features.forEach(function(feature){%><li><%- feature %></li><%}) %></ul><%
      } %>
    <% });}; %>


  CN_VERIFY_TASKS: |
    ## Verification (Linting) Tasks

    Command | Description
    :------ | :----------
    <% if (readme.buildTask) { objectValues(readme.buildTask.verify).forEach(function(value) {
    %><pre><%- value.command %></pre> | <%- value.description %><%
      if (value.features && value.features.length) {
        %><ul><% value.features.forEach(function(feature){%><li><%- feature %></li><%}) %></ul><%
      } %>
    <% });}; %>


  CN_CHANGING_BUILD_TOOL_CONFIG: |
    ## Changing build-tool configuration

    There are 3 ways you can change the build-tool configuration for this project:

    1. BEST: Modify the Confit configuration file (<%= link(configFile) %>) by hand, then re-run `yo confit` and tell it to use the existing configuration.
    1. OK: Re-run `yo confit` and provide new answers to the questions. **Confit will attempt to overwrite your existing configuration (it will prompt for confirmation), so make sure you have committed your code to a source control (e.g. git) first**.
      There are certain configuration settings which can **only** be specified by hand, in which case the first approach is still best.
    1. RISKY: Modify the generated build-tool config by hand. Be aware that if you re-run `yo confit` it will attempt to overwrite your changes. So commit your changes to source control first.

    Additionally, the **currently-generated** configuration can be extended in the following ways:

    - The task configuration is defined in [package.json](package.json). It is possible to change the task definitions to add your own sub-tasks.
    You can also use the `pre...` and `post...` script-name prefixes to run commands before (pre) and after (post) the generated commands.

    <% objectValues(readme.extensionPoint).forEach(function(value) {
    %>- <%- value -%>

    <% }); %>


# Not sure why all this config isn't in one place, not split with npmResources.yml
release:
  defaults:
    useSemantic: true
    commitMessageFormat: Conventional
    checkCodeCoverage: true

  commitMessageFormats:
    - Conventional
    - None

  configSubDir: release/


sampleApp:
  defaults:
    createSampleApp: true

testSystem:
  configSubDir: testSystem/

testUnit:
  configSubDir: testUnit/
  coverageReportSubDir: coverage/

testVisualRegression:
  configSubDir: testVisualRegression/

  defaults:
    enabled: true
    moduleTestDir: visualTest/
    referenceImageDir: visualRegressionTest/referenceImages/

verify:
  # Don't use defaults, as it varies based on the coding standard

  configSubDir: verify/

  # These keys are used in the UI...
  jsCodingStandard:
    ES6:
      - none
      - AirBnB
      - ESLint
      - Google
      - StandardJS
    TypeScript:
      - TypeScript