master, but there has not been a new release since that fix was pushed. Should the issue be closed now, or when there is a new release and the fixed code is available via npm? Or should this be at the discretion of the maintainer?
In the common workflow, issues are used to track the work that needs to be done on a given branch (usually
main, but not necessarily). Once the fix is committed, there's no more work to be done on that branch, and the issue should be closed to signify it. Large projects with more diligent maintainers may also tag the issue to signify what release it will be included in.
If the project uses a different issue tracker than GitHub issues, it may use two different statuses for these two actions - a "modified" or "merged" status for when the fix is committed to the relevant branch and an additional "closed" or "fixed" status for when the release is performed.
In my opinion - and I should stress it's only that - it's great that you've found a bug in a piece of free software. It's good to find bugs, because it makes software better. That said, if you report the bug, the maintainer is not obliged to fix it. If you fix it, the maintainer is not obliged to accept your fix. If your fix is accepted, you're not entitled to any particular workflow with respect to the release of that fix and the closure of the bug report.
The reasonable expectations you can have of free software are laid out in the licence, and reiterated in the Four Freedoms. If you come across a piece of free software that has bugs, you have the right to copy it, fix the bugs, and redistribute the modified version, because it's free software. Everything else is discretionary.