ungoldman / changelog-parser Goto Github PK

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.

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

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.

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.

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 .

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

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 );

IS IT WORTH IT?

https://github.com/wooorm/mdast

Hey,

I've got a few questions regarding the future of this package:

1. Is there any active development done?
2. Are there any plans for updates? e.g. for browser support for parsing changelog etc.
3. If the answers above are both no, is it ok to fork the project and revitalize its work under the same or new npm package? I've written a couple of projects and pipelines with this package and would love to bring it up to date with various improvements, but wouldn't want to do it without consent. What I see missing, but I've already done on couple of occasions on my own:
   • Browser support and general cross-environment functionalities (esm/cjs etc)
   • Modifiable regex patterns
   • Custom fields extracted from regex groups
   • Exports for useful functions
   • Entry post-processing (e.g. adding links to ticket numbers), filtering and grouping

If these don't align with the package vision, that's fine, but I'd love to have at least consent to reuse some of this code for my own public package.

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.

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.

• 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/

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);
            });
        });
    });
});

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

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?

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.

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.

My change is like this:

## [2.3.4]
### bugfix
- something 1
  - desc 1
  - desc 2
- something 2
  - desc 1
  - desc 2

But It is parsed like this:

## [2.3.4]
### bugfix
- something 1
- something 2

As you can see, it ignores subtitles and removes them!