accept input text instead of file

[jedwards1211]

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.

[ungoldman]

not sure why this library only supports passing a file path

it's because that's what was needed when this was written 😄

I'm trying to parse a changelog I've fetched from GitHub instead of a file

that sounds fine, please feel free to open a PR adding text as an option

https://github.com/hypermodules/changelog-parser#options

[jedwards1211]

in the course of working on this I also discovered that some packages use the other heading style in their changelogs (e.g. Sinon):

7.3.2 / 2019-04-17
==================

  * Update Lolex to bring in fix for sinonjs/lolex#232 (queueMicrotask warning)

7.3.1 / 2019-03-27
==================

  * Fix security issues
  * Update @sinonjs/samsam to v3.3.1

There's a lot of variation in dates too (Material UI uses Apr 29, 2019 style)
So I wrote some simple parsing code of my own for the time being, but I'll go ahead and PR the changes I started working on to this package

[ungoldman]

Yes, there are a lot of different changelog flavors out there! This parser doesn't attempt to cover all of them, and mostly targets the standard provided by https://keepachangelog.com.

An exception was made in the past to cover a variation introduced by conventional-changelog. A pull request was merged to make that generator more semantic and conformant to the standard, but its release has been stalled for some time.

As the primary maintainer of this small package, I currently have no intention of further modifying the parser to accept all possible variations. This package exists mainly to support a couple of release utilities (primarily gh-release) (though I'm surprised to see changelog-parser has about 5k more downloads per month than its parent package!).

Maintaining support for a wide variety of changelog variations that don't respect a basic standard is not something I can do in my limited spare time as an open source maintainer. If some enterprising person is willing to take that on and shows some ability to follow through long-term, I would welcome them :)

Alternately, if this is a strong requirement of yours for a project you're working on, you're welcome to fork this project and publish an alternative supporting more changelog formats. Best of luck, whichever path you choose!