nextstrain
Nextclade dataset reference trees
See commit messages for details.
Some previews to check out:
- https://nextstrain-s-trs-nextcl-e9eixu.herokuapp.com/nextclade
- https://nextstrain-s-trs-nextcl-e9eixu.herokuapp.com/nextclade/sars-cov-2 (redirects)
- https://nextstrain-s-trs-nextcl-e9eixu.herokuapp.com/nextclade/sars-cov-2@2025-01-01
- https://nextstrain-s-trs-nextcl-e9eixu.herokuapp.com/nextclade/nextclade/mpox/clade-iib
-
nextstrain remote ls https://nextstrain-s-trs-nextcl-e9eixu.herokuapp.com/nextclade -
nextstrain remote download https://nextstrain-s-trs-nextcl-e9eixu.herokuapp.com/nextclade/nextclade/mpox/clade-iib
Resolves: https://github.com/nextstrain/nextstrain.org/issues/1156
Checklist
- [ ] ~Omit Nextstrain logo for community datasets (although our listings for Groups do not do this yet either)~ see https://github.com/nextstrain/nextstrain.org/issues/870#issuecomment-3487636755
- [x] Checks pass
- [x] Check if changes affect the resource index JSON revision
Two linting errors in CI did not appear locally for me… ah, because I ran npm run lint which is really npm run lint:server and not also npm run lint:static-site. Why is the unqualified "lint" not both?
In any case, the linting didn't like two places I use ! like this:
"some string".split("another string")[0]!
I used the ! because the array index types as string | undefined, which is erroneous: string.split always returns an array of one string element.
I guess I'll tell eslint to go stuff it?
Omit Nextstrain logo for community datasets (although our listings for Groups do not do this yet either)
Illustrated:
and the Groups pages with the same issue:
Punting on the logo issue as part of https://github.com/nextstrain/nextstrain.org/issues/870#issuecomment-3487636755 instead.
A good conversation about forwards compatibility with Nextclade's index and breaking changes is happening in Slack, started by @ivan-aksamentov.
Why is the unqualified "lint" not both?
Reasoning is in cc763094726d7ea6501f8087da026d880fddd3e1 but I also think it should be both (see 1ebb0a92516bc1b65b280090c8ba12aee4757340 in #1076)
