conventional-changelog/standard-version

feat: add configuration option for GitLab/BitBucket URLs

Open

#227 opened on Nov 29, 2017

View on GitHub
 (2 comments) (13 reactions) (0 assignees)JavaScript (7,442 stars) (825 forks)batch import
enhancementhelp wanted

Description

I would like to introduce config options to standard-version, in the form of a .svrc and a standard-version stanza in the package.json; This functionality is built into yargs:

https://github.com/yargs/yargs/blob/master/docs/advanced.md#configuration

I think the first feature we should support is adding the ability to use GitLab and BitBucket style URLs (see https://github.com/conventional-changelog/standard-version/issues/204, https://github.com/conventional-changelog/standard-version/pull/174).

@cdupetit could we potentially simplify the process of providing context for gitlab; it feels like --context requires a lot of variables be specified. I'd prefer that we override a few in the package.json.

Contributor guide

Tech stack
javascriptnodejs
Domain
toolingrelease
Issue type
feature
DifficultyEstimated implementation difficulty for a new contributor, from 1 for very small changes to 5 for expert-level work.
3
Estimated timeA rough time range for an experienced contributor to investigate, implement, test, and prepare a pull request.
1-2 days
Activity statusHow available the issue appears right now: fresh, active, stale, blocked, or waiting on maintainer input.
stale
ClarityHow clearly the issue explains the expected change, acceptance criteria, and next step.
mostly clear
Prerequisites
basic knowledge of standard versionfamiliarity with yargs configuration
Newbie friendlinessA 1-100 score estimating how approachable this issue is for first-time contributors.
35
Research direction
Investigate the existing CLI argument parsing in standard version, likely using yargs. Look at the proposed .svrc config file and the 'standard version' stanza in package.json. Refer to linked issues #204 and PR #174 for context on GitLab/BitBucket URL handling. The main task is to extend the configuration to allow overriding URL patterns for different git hosting services, similar to how yargs handles configuration. Examine the package.json and any existing config loading logic to determine where to integrate the new options.