virtualstate / navigation

Native JavaScript navigation [web api] implementation
MIT License
72 stars 5 forks source link

Feature request: Changelog #20

Open loganvolkers opened 10 months ago

loganvolkers commented 10 months ago

Can I politely and kindly request that this project adopt a changelog as per keep a changelog?

What is a changelog?

A changelog is a file which contains a curated, chronologically ordered list of notable changes for each version of a project.

Why keep a changelog?

To make it easier for users and contributors to see precisely what notable changes have been made between each release (or version) of the project.

Who needs a changelog?

People do. Whether consumers or developers, the end users of software are human beings who care about what's in the software. When the software changes, people want to know why and how.

fabiancook commented 10 months ago

Very reasonable!

We haven't yet made a "stable" release yet, and the module is marked as alpha right now, but maybe with further polyfill support that we have recently got, it might be time, and along with releases from there further a change log would be the way to go.

loganvolkers commented 10 months ago

Thanks @fabiancook my other issue was going to be a roadmap to stable and a contributing guide. WPT.md looks like it might be outdated.

fabiancook commented 10 months ago

Ah yes WPT.md is a generated file that needs updating, it shows a pretty good view of what is and isn't considered, but, these WPT are best effort as I am using a shim to utilise them to begin with and we don't really fit every case available.

Some tests that hadn't been passing in the automatic WPT, but I thought should have, I had split these out into individual tests...

Maybe this is what needs to be done for every failing WPT available, and exclude the ones that we have a written test from the failed list.

It really sounds like we need a compatibility table.

Ideally we want 100% compatibility with the spec... as far as I know the newest functions like scroll is one of the bigger remaining features to implement, but known too there are things like hash change for the current entry, and there is a few TODO comments to address

To confirm this compatibility, complete coverage of the WPT for the navigation API should be achieved, or the failing tests should be manually reviewed and confirmed whether or not it should be within scope.

Ideally the polyfill should be testable within these same WPT constraints, right now it is being tested in node/deno/bun/playwright, but only against the written tests.

With chrome implemented the navigation api, and other browsers showing positive intent to ship the feature, it seems like its nearing time for this module to be released as a v1 too.