navigation
navigation copied to clipboard
Feature request: Changelog
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.
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.
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.
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.
I've now started a "whats changed log" here: https://github.com/virtualstate/navigation?tab=readme-ov-file#whats-changed
Its not much, but I'll at least keep the bigger changes listed, and make a standalone "CHANGELOG" file once we get a bit more going. Might be soon time to drop the alpha
prerelease id from the version.