<commit_before>'use strict';

var yeoman = require('yeoman-generator');
var chalk = require('chalk');
var yosay = require('yosay');
var path = require('path');
var hasbin = require('hasbin');

var BakeryGenerator = yeoman.Base.extend({

  constructor: function() {
    yeoman.Base.apply(this, arguments);
    this._options.help.desc = 'Show this help';

    this.existingProject = false;

    this.argument('projectname', {
      type: String,
      required: false,
      defaults: ''
    });

    /*
      Sets a working directory. The will be staged in [working dir]/[project name]. This prevents
      the CWD (ie. generator-bakery/) from being used as a working directory. If generator-bakery/
      is used the staging directory becomes a nested Git project causing all sorts of havoc.
    */
    this.option('workingdir', {
      type: String,
      alias: 'w',
      desc: 'Identifies a parent directory for the output of this generator',
      defaults: ''
    });

    this.option('awsprofile', {
      type: String,
      alias: 'p',
      desc: 'Name of the AWS profile to use when calling the AWS api for value validation',
      defaults: 'default'
    });
  },

  initializing: function() {
    // establish default
    let defaultConfig = {
      projectname: this.projectname
    };
    this.config.defaults(defaultConfig);

    // this seem vestigal - @pmmclory?
    var configFound = this.baseName !== undefined && this.applicationType !==
      undefined;
    if (configFound) {
      this.existingProject = true;
    }
  },

  prompting: function() {
    // Have Yeoman greet the user.
    this.log(yosay(
      'Welcome to the super-excellent ' + chalk.red('bakery') +
      ' generator!'
    ));

    // If projectname is not supplied as an argument at the command line collect it here
    let prompts = [{
      name: 'projectname',
      type: 'input',
      message: 'Project name',
      when: () => {
        return this.projectname.length < 1;
      },
      // on first-run this uses value set in 'initializing'. Subsequently values are read
      //  from .yo.rc.json
      default: this.projectname || this.config.get(
        'projectname'),
      required: true
    }];

    return this.prompt(prompts).then(function(props) {
      /*
        we're using the Yeoman-native config system. This means all config gets stored in
        .yo.rc.json in the CWD. Values gathered from the top-level generator (this one) are
        stored in top-level keys in .yo.rc.json. Each sub-generator will store its properties
        in a key named after itself. For example bakery:scm will store its properties under
        the 'scm' key. THIS IS BY CONVENTION ONLY. The logic is implemented in each generator.
        If this is a pattern we like we ought probably to subclass the Yeoman Base class into
        a BakeryBase and code this convention as part of the framework.

        Note: config.set(...), config.get(...), and config.defaults(...) operate on top-level
         keys only. config will not do a deep merge when you set/get things. So beware the
         clobberage.
      */
      this.config.set('projectname', this.projectname || this.config
        .get('projectname'));
      this.config.set('source', props.source);

      /*
        the call to config.save does not appear to write to disk until sometime late in the
        generator lifecycle. Perhaps this is due to the in-memory fs Yeoman uses? Perhaps<commit_msg>resolve an issue with prompting for projectname<commit_after>'use strict';

var yeoman = require('yeoman-generator');
var chalk = require('chalk');
var yosay = require('yosay');
var path = require('path');
var hasbin = require('hasbin');

var BakeryGenerator = yeoman.Base.extend({

  constructor: function() {
    yeoman.Base.apply(this, arguments);
    this._options.help.desc = 'Show this help';

    this.existingProject = false;

    this.argument('projectname', {
      type: String,
      required: false,
      defaults: ''
    });

    /*
      Sets a working directory. The will be staged in [working dir]/[project name]. This prevents
      the CWD (ie. generator-bakery/) from being used as a working directory. If generator-bakery/
      is used the staging directory becomes a nested Git project causing all sorts of havoc.
    */
    this.option('workingdir', {
      type: String,
      alias: 'w',
      desc: 'Identifies a parent directory for the output of this generator',
      defaults: ''
    });

    this.option('awsprofile', {
      type: String,
      alias: 'p',
      desc: 'Name of the AWS profile to use when calling the AWS api for value validation',
      defaults: 'default'
    });
  },

  initializing: function() {
    // establish default
    let defaultConfig = {
      projectname: this.projectname
    };
    this.config.defaults(defaultConfig);

    // this seem vestigal - @pmmclory?
    var configFound = this.baseName !== undefined && this.applicationType !==
      undefined;
    if (configFound) {
      this.existingProject = true;
    }
  },

  prompting: function() {
    // Have Yeoman greet the user.
    this.log(yosay(
      'Welcome to the super-excellent ' + chalk.red('bakery') +
      ' generator!'
    ));

    // If projectname is not supplied as an argument at the command line collect it here
    let prompts = [{
      name: 'projectname',
      type: 'input',
      message: 'Project name',
      when: () => {
        return this.projectname.length < 1;
      },
      // on first-run this uses value set in 'initializing'. Subsequently values are read
      //  from .yo.rc.json
      default: this.projectname || this.config.get(
        'projectname'),
      required: true
    }];

    return this.prompt(prompts).then(function(props) {
      /*
        we're using the Yeoman-native config system. This means all config gets stored in
        .yo.rc.json in the CWD. Values gathered from the top-level generator (this one) are
        stored in top-level keys in .yo.rc.json. Each sub-generator will store its properties
        in a key named after itself. For example bakery:scm will store its properties under
        the 'scm' key. THIS IS BY CONVENTION ONLY. The logic is implemented in each generator.
        If this is a pattern we like we ought probably to subclass the Yeoman Base class into
        a BakeryBase and code this convention as part of the framework.

        Note: config.set(...), config.get(...), and config.defaults(...) operate on top-level
         keys only. config will not do a deep merge when you set/get things. So beware the
         clobberage.
      */

      // there are three ways to set a projectname, 1) through an argument passed via cli
      //   2) the .yo-rc file, and 3) the projectname prompt.  Adding in the ability to set
      //   projectname via prompt
      this.config.set('projectname', this.projectname || props.projectname || this.config
        .get('projectname'));
      this.config.set('source', props.source);

      /*
        the call to config.save does not appear to write to disk until sometime late in the
        generator lifecycle. Perhaps this is due to the in-memory fs Yeoman uses? Perhaps
{'fraction_non_alphanumeric': 0.10294526257293693, 'fraction_numerical': 0.0006946373992775772, 'mean_word_length': 2.548053228191227, 'pattern_counts': {'":': 0, '<': 5, '<?xml version=': 0, '>': 5, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '1832370', 'n_tokens_mistral': 2014, 'n_tokens_neox': 1952, 'n_words': 759}