Standard-version: Github Enterprise URL's are being made plural

[patrickmichalina]

It is generating an extra "s" on the commit portion of the uri. When clicking, it shows ALL commits. No very useful, I want to see commit/#hash. Any reason the system would be doing this? I don't see it happening in this repo's changelog

Ex:
https:/github.com/thinger/thingy/commits/g762af5

[bcoe]

@patrickmichalina this definitely doesn't sound right! would love the help digging into this if you have the time otherwise hopefully myself, @Tapppi, or one of the other core maintainers will have a chance to look soon.

[Tapppi]

@bcoe I tried to scour https://github.com/conventional-changelog/conventional-changelog-angular and https://github.com/conventional-changelog/conventional-changelog-core a bit but couldn't find anything that would cause this.. github has only commit: 'commit' as the host commit ref. @patrickmichalina any chance you have an example that can reproduce this?

[bcoe]

@patrickmichalina a failing test would kick butt 👍 would help us get this patched ASAP.

[patrickmichalina]

@bcoe I am new to this tooling and wondering if re-based or merged commits could be doing this? I will try to see if I can find out more information about why this might be happening.

[patrickmichalina]

@Tapppi the only thing with "commits" in those repos is for this test:

it('should work with unknown host', function(done) {
    preparing(7);
    var i = 0;

    conventionalChangelogCore({
      config: preset,
      pkg: {
        path: __dirname + '/fixtures/_unknown-host.json'
      }
    })
      .on('error', function(err) {
        done(err);
      })
      .pipe(through(function(chunk, enc, cb) {
        chunk = chunk.toString();

        expect(chunk).to.include('(http://unknown/compare');
        expect(chunk).to.include('](http://unknown/commits/');

        i++;
        cb();
      }, function() {
        expect(i).to.equal(1);
        done();
      }));
  });

this line

expect(chunk).to.include('](http://unknown/commits/');

Haven't dug deep, but the name of the test might mean "if not github.com". Not sure why that would matter though. But this may be specific to github enterprise (which is where this is happening!). I checked another private repo for a github.com hosted app an it doesn't appear to be happening.

[Tapppi]

Ah, thank you for the clarification about github enterprise @patrickmichalina, I was just going to ask what host you use.. Is there any chance you can share the "repository" field for your package? This line seems to be the culprit: https://github.com/conventional-changelog/conventional-changelog-core/blob/master/lib/merge-config.js#L171 It checks for the host with a regex. If your url doesn't contain github, it would result in the unknown host and as such cause your problems.

[patrickmichalina]

obscuring a little of the actual name, for privacy reasons.

"repository": {
    "type": "git",
    "url": "[email protected]:group/some-project.git"
},

[Tapppi]

Yeah, so the problem is that your host doesn't have "github" in it, causing it to be detected as an unknown host with wrong defaults for the changelog writes. @stevemao @bcoe I'm not sure how we should proceed with this, I don't think there is any way to autodetect github enterprise.. Maybe there should be an override for the host type?

[bcoe]

@Tapppi @stevemao how about a standard-version config stanza in your package.json, allow people to specify an override for repository type. @stevemao could you make it so we can kick this configuration setting along as a hint to the renderer, with it guessing if it's blank?

[stevemao]

How about using https://www.npmjs.com/package/cosmiconfig to get the config?

[Tapppi]

:+1: for using cosmiconfig, seems super simple! What should we use as options? e.g.

// I like:
package.json `{"standard-version": {...}}`
.standard-version (or .standard-version.yaml/.standard-version.json??)
// I dont like, but am open to:
standard-version.config.js
`--config` CLI arg, since we have IMO very good cli options

[bcoe]

@Tapppi @stevemao definitely a bit biased, _but_ I maintain yargs., and its config management is pretty slick at this point:

https://github.com/yargs/yargs#configkey-description-parsefn

It supports both config files, package stanza configuration, and allows you to extend other config files.

[patrickmichalina]

# I tend to favor:
package.json `{"standard-version": {...}}`

[bcoe]

@Tapppi @stevemao, actually., since we already use yargs in standard-version I think we basically just need to have .pkgConf('standard-version') as soon as we're ready to have some configuration options:

https://www.npmjs.com/package/yargs#pkgconfkey-cwd

[stevemao]

Sorry didn't know yargs already did it :) Sounds good :)

[Tapppi]

Sounds great, had no idea it could do that, yargs is just so big that I can never remember all the stuff it does!

[stevemao]

Maybe we could also use commitizen's .czrc file? since folks using this module maybe already using commitizen

[bashmish]

I would suggest to have a different config file for standard-version, because it seems to be pretty independent from other tools and should stay such. And https://github.com/davidtheclark/cosmiconfig would be awesome. I can work on a MR.

@bcoe can you confirm that you are interested in supporting this feature?

[knksmith57]

while I do favor migrating to cosmiconfig, the feature I find myself wishing standard-version provided is the ability to carve lifecycle scripts _out_ of package.json and into a separate file.

it looks like, with a small amount of tweaking, this is possible w/ the existing yargs setup.

are there any objections to enabling configuration via external file _if_ yargs.config() is used to do so, @bcoe?

[bcoe]

@patrickmichalina 👋 took a while, but we finally added the ability to customize URLs, as of [email protected] you can now specify compareUrlFormat, commitUrlFormat, etc., which allow to specify URL patterns other than GitHub.com.