ungoldman / changelog-parser Goto Github PK

Just noticed log and current variables are declared at the module level and assigned at the function level, which is bad. Will refactor a bit to assign variables to be returned a little more intelligently.

My changelog is generated by Lerna and looks something like this

# [12.98.0](https://some-git-link) (2022-08-23)


### Features

* **jira-1234:** add some new stuff [incomplete] ([24b358b](https:git-some-link))

When parsed, I use the versions[0].parsed["_"], however the value is jira-1234: add some new stuff incomplete] ([24b358b).

It looks like the [] is confusing the parsing logic and outputs in the wrong place.

• regex: ^#{1,2} ([0-9\.A-Za-z-]+)\s?\/?\s?(\d{4}-\d{2}-\d{2}|\w+)? (from http://tech-angels.github.io/vandamme/)
• https://github.com/sindresorhus/semver-regex
• http://keepachangelog.com/

Currently, parseChangelog() expects a callback argument, which allows the user to access the parsed changelog data with the body of the function. Eg.

// Callback functionality
parseChangelog( 'path/to/file', function( err, result ) {
    if ( err ) return;

    console.log( result );
} );

Proposed update would supplement the current functionality/behavior by returning a Promise in cases where parseChangelog is not invoked with a callback. Eg.

// Promise functionality
parseChangelog( 'path/to/file' )
    .then( function( result ) {
        console.log( result )
    } )
    .catch( function() {
        // Whoops, something went wrong!
    } );

This update would allow parseChangelog() to be easily inserted into 'Promise chain' procedures. Eg.

let result = getPath( 'CHANGELOG.md' )
                .then( parseChangelog )
                .then( getVersions );

First of all, great project. 👍

I made https://github.com/ocavue/changelog-parser-action on the top of this project. Users can use changelog-parser-action to parse CHANGELOG in their GitHub Action workflows and combine it with other Actions together.

Any feedback and suggestions will be appreciated.

Parallel to the version it would be nice to have the date extracted into its own key in the version object.

It seems that when parsing a change-log file across Linux and Windows, the output object is different.

When parsing a change-log on windows, the title field is filled but the body is empty, on Mac it's the opposite...

Windows Output

{ version: '15.5.1',
  title:
   '15.5.1\n\n### SUB-HEADING (Category)\n- Item 1\n- Item 2\n\n### SUB-HEADING (Category)\n- Item 3\n- Item 4\n\n## 15.5.0\n\n### SUB-HEADING (Category)\n- Item 6\n- Item 2\n\n### SUB-HEADING (Category)\n- Item 1\n- Item 4\n\n### SUB-HEADING (Category)\n- Item 7\n- Item 14',
  date: '15.5.0',
  body: '',
  parsed: { _: [] } }

Linux Output

{ version: '15.5.1',
  title: '',
  date: '15.5.0',
  body: '
   '15.5.1\n\n### SUB-HEADING (Category)\n- Item 1\n- Item 2\n\n### SUB-HEADING (Category)\n- Item 3\n- Item 4\n\n## 15.5.0\n\n### SUB-HEADING (Category)\n- Item 6\n- Item 2\n\n### SUB-HEADING (Category)\n- Item 1\n- Item 4\n\n### SUB-HEADING (Category)\n- Item 7\n- Item 14'',
  parsed: { _: [..] } }

https://github.com/hypermodules/changelog-parser/blob/ef3202f250019b46692c234d5c6d354795255e4a/index.js#L83 could possibly be a good place to investigate

Parser output now includes a 'date' key on each version object, but this is not reflected in the README.md example.

Happy to submit a PR for this.

P.S. Apologies, I should have included this update with my original PR against #6 .

Is there any plan to implement the feature to write back into the changelog markdown file?

This feature is useful to programmatically update the changelog, for example in auto release job.

currently it appears that changelog-parser only works w/ file paths. however, i'd like to pass in a string (pulled from a github graphql query) rather than a file path. is this possible?

for example:

let md = "#some markdown in a changelog ... (versions, changes etc)";

let result = await parseChangelog(md);

console.log("the versions: ", result.versions) 

is this possible? I'm not super familiar w/ line-reader but maybe something like this would help? https://github.com/feross/string-to-stream

I have markdown comments in my changelog to remind me of the format. This module accidentally parses it as a release. I assume this behavior is unwanted.

When a changelog is produced on one platform (e.g. MacOS), with it's style of line endings (e.g. LF), when trying to run the changelog-parser on another platform (e.g. Windows), it tries to use the current OS'es line endings style (e.g. CRLF), and will parse the entire file as one 'line'.

An option should be added to be able to supply a custom line endings style (or automatically detect style from changelog file), so that this can be used in source-controlled projects across multiple platforms.

It appears that if you attempt to read the file after it has been read and modifed, changelog-parser is will still output the old information.

Here is a quick repro test case:

const changelogParser = require('changelog-parser');
const fs = require('fs');
const path = require('path');

const changelog = path.join(__dirname, 'CHANGELOG.md');

changelogParser(changelog, (err, result) => {
    // Print parsed result. Note: 0.2.3 is latest version
    console.log(result);

    // Read the changelog file
    fs.readFile(changelog, 'utf-8', (err, content) => {
        // Change version 0.2.3 to 1.0.0
        const newContent = content.replace('0.2.3', '1.0.0');
        fs.writeFile(changelog, newContent, 'utf-8', () => {
            console.log("FILE WRITTEN....");

            // Parse the file again
            changelogParser(changelog, (err, result) => {

                // BUG: Still says 0.2.3 even though file was written with new 1.0.0 version
                console.log(result);
            });
        });
    });
});

not sure why this library only supports passing a file path, I'm trying to parse a changelog I've fetched from GitHub instead of a file.

https://github.com/conventional-changelog/standard-version produces change logs with versions that have different heading sizes. This breaks the parser. In a perfect world they wouldn't do that, but for now the parser should not fail if headings are not consistent.

IS IT WORTH IT?

https://github.com/wooorm/mdast

Currently, all markdown/data for a given entry is provided via the body key on the changelog object. This is perfect for many use cases, but I've bumped into a situation where I need access to the individual items of a specific type from a particular entry (eg. everything 'Added' as part of '1.0.0'). To achieve this, I'm parsing the markdown (provided via body) into a series of plain text arrays.

If possible, I would love to have this information made available 'out of the box' for each entry.

For example, the following entry...

## [1.0.0] - 2018-01-04
### Added
- Added `gh-release` to development dependencies.

### Changed
- Updated dependency version.
- Fixed broken tests.

...would be parsed to:

{
    version: '1.0.0',
    title: '[1.0.0] - 2018-01-04',
    date: '2018-01-04',
    body: '## [1.0.0] - 2018-01-04 ...',
    bodyParsed: {
        added: [
            'Added `gh-release` to development dependencies.',
        ],
        changed: [
            'Updated dependency version.',
            'Fixed broken tests.',
        ],
    },
}

If you approve, I'm happy to take a crack at building out/testing this functionality?