Provide regex/prefixes per file set

[vpratfr]

In WordPress plugin development, the version number is in various files, at least the following:

• package.json (version: "1.0.0")
• readme.txt (Stable release: 1.0.0)
• my-plugin.php (Plugin version: 1.0.0)

What happens is that bump does not find the version number in the txt and php files I mentionned.

I can do that with another grunt plugin: https://github.com/kswedberg/grunt-version

You can specify with each file set a prefix. This looks like that for a WordPress plugin:

{
    plugin_file:{
        options: {
            prefix: "Version:\\s*"
        },
        src: ["my-plugin.php"]
    },
    readme_txt:{
        options: {
            prefix: "Stable tag:\\s*"
        },
        src: ["readme.txt"]
    },
    package:{
        src: ["package.json"]
    }
}

However, that plugin has its own weaknesses and feels less mature than yours.

Would be great if we could pass this kind of prefix/regex for each fileset in grunt-bump

[eddiemonge]

While that sounds like it might be good, for your specific use case I would question why you need the version in so many places. If you aren't publishing on npm, then package.json doesn't really need it. Why does the readme need it as well?

[vpratfr]

Hi,

Versioning is a pain with WordPress themes and plugins. These files are the
minimal files you need and each of them will see this version number.

I want to use the package.json as the unique source for version number in
order to avoid different version numbers in different places. I also use
that as a source for the git commits and tags done by grunt.

[ingo]

+1. I'd like to use grunt-bump in all my projects, but writing a regex to cover all cases is somewhat problematic.

[eddiemonge]

If someone wants to write up an api and/or help docs for this, it would make it easier to approve and implement

[vpratfr]

Hi,

I think from the configuration point of view, it could look like that:

grunt.initConfig({
  bump: {
    options: {
      files: {
        'package.json' : {
          regex: false,
          commit: true
        },
        'readme.txt' : {
          regex: 'Stable tag:\\s*',
          commit: true
        }
      },
      updateConfigs: [],
      commit: true,
      commitMessage: 'Release v%VERSION%',
      commitOtherFiles: ['readme.md'],
      createTag: true,
      tagName: 'v%VERSION%',
      tagMessage: 'Version %VERSION%',
      push: true,
      pushTo: 'upstream',
      gitDescribeOptions: '--tags --always --abbrev=1 --dirty=-d',
      globalReplace: false,
      prereleaseName: false
    }
  },
})

Above you can notice the differences:

1. Files are now objects
   • key is the file globbing pattern
   • value is an object with a few properties that apply only to this file set
     • regex is the regular expression to find the version number for that file set (or false to use plugin's default)
     • commit is a shortcut to tell to add that file set to the commit (this is an improvement to avoid having to specify those same file sets again in the global commit parameter)
2. The global option 'commitFiles' has been renamed to 'commitOtherFiles' in case someone wants to specify more files to commit (maybe for example some files which would be generated between the bump and the commit).
3. The global option 'regExpr' is not needed anymore as this is specified by file set.

[matih]

+1

[siamkreative]

@vpratfr Salut Vincent!

I'm currently using grunt-version, which works well for version bumps, but it doesn't handle git tag/commit/release/push like grunt-bump does.

Below is an example task:

bump: {
    packageJson: {
        options: {
            files: ['package.json']
        }
    },
    pluginConstant: {
        options: {
            regExp: 'define\\(\\s*\'WR_VERSION\',\\s*\'',
            files: ['plugin-reviews.php']
        }
    },
    stableTag: {
        options: {
            regExp: 'Stable tag:\\s+',
            files: ['readme.txt']
        }
    }
},

If you're confident with writing grunt-plugins, then perhaps you can take a look at how Grunt-Version does it. I really wish I could help more, but I far from being a Node JS expert...

[MikeSpock]

Until this pull request is approved, you can use the improved grunt bump in your package.json like this:
"grunt-bump": "MikeSpock/grunt-bump#master"