Nitpick docs (#209)

- Consistently refer to Node.js as Node.js, not Node.
- Other minor improvements.

frontend/docs/about-slow-types.md

@@ -1,11 +1,11 @@
 ---
-description: JSR uses TypeScript types to generate docs and improve node compat. "Slow types" can get in the way of this.
+description: JSR uses TypeScript types to generate documentation and improve Node.js compatibility. "Slow types" can get in the way of this.
 ---
 
 In many of its features, JSR analyzes source code, and in particular TypeScript
 types in the source code. This is done to generate documentation, generate type
 declarations for the npm compatibility layer, and to speed up type checking of
-projects using JSR packages in Deno.
+Deno projects using packages from JSR.
 
 For these features to work, the TypeScript source must not export any functions,
 classes, interfaces, or variables, or type aliases, that are themselves or

frontend/docs/api.md

@@ -151,7 +151,7 @@ metadata. Instead, retrieve yanked status from the package metadata.
 The npm compatibility registry API is used to download npm compatible tarballs
 for JSR packages, and to retrieve npm compatible package metadata.
 
-[Learn more about the npm compatibility layer](/docs/npm-compatibility).
+[Learn more about the npm compatibility layer.](/docs/npm-compatibility)
 
 The npm compatibility registry API is served from the `https://npm.jsr.io`
 domain.

frontend/docs/badges.md

@@ -1,63 +1,62 @@
 ---
-description: JSR provides a badges for each package that can be used to showcase the package version or JSR score for a package.
+description: JSR provides badges for each package that can be used to showcase its latest version or its JSR score.
 ---
 
-For every package, JSR provides an SVG badge that can be included in READMEs,
-documentation, or other places to showcase the package version or JSR score for
-a package.
+JSR provides badges for each package that can be used to showcase its latest
+version or its JSR score.
 
 ## Version Badge
 
-The version badge is a simple way to show the version of a package. It is
+The version badge can be used to showcase the version of a package. It is
 available at the following URL:
 
 ```
 https://jsr.io/badges/@<scope>/<package>
 ```
 
-It looks like this:
+Here's how it looks:
 
 [![JSR](https://jsr.io/badges/@luca/flag)](https://jsr.io/@luca/flag)
 
-To include it in a markdown document, copy the following code and replace
-`<scope>` and `<package>` with the scope and package name of the package.
+To include it in a Markdown document, use the following code, replacing
+`<scope>` and `<package>` with the actual scope and name of the package.
 
 ```markdown
-[![](https://jsr.io/badges/@<scope>/<package>)](https://jsr.io/@<scope>/<package>)
+[![JSR](https://jsr.io/badges/@<scope>/<package>)](https://jsr.io/@<scope>/<package>)
 ```
 
-In a HTML document, use the following code:
+In HTML documents, the following can be used:
 
 ```html
 <a href="https://jsr.io/@<scope>/<package>">
-  <img src="https://jsr.io/badges/@<scope>/<package>" alt="">
+  <img src="https://jsr.io/badges/@<scope>/<package>" alt="" />
 </a>
 ```
 
 ## JSR Score Badge
 
-The JSR score badge is a way to show the JSR score of a package. It is available
-at the following URL:
+The JSR score badge can be used to showcase the JSR score of a package. It is
+available at the following URL:
 
 ```
 https://jsr.io/badges/@<scope>/<package>/score
 ```
 
-It looks like this:
+Here's how it looks:
 
 [![JSR Score](https://jsr.io/badges/@luca/flag/score)](https://jsr.io/@luca/flag)
 
-To include it in a markdown document, copy the following code and replace
-`<scope>` and `<package>` with the scope and package name of the package.
+To include it in a Markdown document, use the following code, replacing
+`<scope>` and `<package>` with the actual scope and name of the package.
 
 ```markdown
-[![](https://jsr.io/badges/@<scope>/<package>/score)](https://jsr.io/@<scope>/<package>)
+[![JSR Score](https://jsr.io/badges/@<scope>/<package>/score)](https://jsr.io/@<scope>/<package>)
 ```
 
-In a HTML document, use the following code:
+In HTML documents, the following can be used:
 
 ```html
 <a href="https://jsr.io/@<scope>/<package>">
-  <img src="https://jsr.io/badges/@<scope>/<package>/score" alt="">
+  <img src="https://jsr.io/badges/@<scope>/<package>/score" alt="" />
 </a>
 ```

frontend/docs/faq.md

@@ -6,10 +6,10 @@ description: Answers to frequently asked questions about JSR.
 ### What is JSR?
 
 JSR is a new package registry for JavaScript. It is a free alternative to npm,
-that is designed to work well with all JavaScript tools and runtimes, like Node,
-Deno, Bun, Vite, and more.
+that is designed to work well with all JavaScript tools and runtimes, like
+Node.js, Deno, Bun, Vite, and more.
 
-[Learn more about "Why JSR?".](/docs/why)
+[Learn more about why we built JSR.](/docs/why)
 
 ### How do I use JSR?
 
@@ -41,7 +41,7 @@ seamlessly work with JSR. JSR is designed to be better than npm:
 - No need for build steps, which leads to better user experience for package
   publishers
 - Secure, token-less publishing for resistance against supply chain attacks
-- and more... [Learn more about "Why JSR?".](/docs/why)
+- and more... [Learn more about why we built JSR.](/docs/why)
 
 ### How is JSR funded? / Do I have to pay for JSR?
 
@@ -57,14 +57,14 @@ foreseeable future - JSR is designed to be very cheap to run.
 ### Can I delete a package from JSR?
 
 Source code published to JSR can not be deleted.
-[Learn more about immutability](/docs/immutability).
+[Learn more about immutability.](/docs/immutability)
 
 You can "yank" a version of a package, which will hide the version from the
 default view, but it will still be available to users who depend on it.
-[Learn more about yanking](/docs/packages#yanking-versions).
+[Learn more about yanking.](/docs/packages#yanking-versions)
 
 You may delete a package if it has no published versions.
-[Learn more about deleting empty packages](/docs/packages#deleting-a-package).
+[Learn more about deleting empty packages.](/docs/packages#deleting-a-package)
 
 ### Why are there quotas for scopes and package versions on JSR?
 

frontend/docs/immutability.md

@@ -46,7 +46,7 @@ version number in your config file before publishing a new version.
 
 You can't delete a package version after it has been published. However, you can
 publish a new version of your package and yank the old version.
-[Learn more about yanking](/docs/packages#yanking-versions).
+[Learn more about yanking.](/docs/packages#yanking-versions)
 
 Note that yanking does not remove the contents of the package version from the
 registry. It only superficially hides the version from users in some places.

frontend/docs/introduction.md

@@ -4,9 +4,9 @@ description: JSR is a new modern package registry for JavaScript and TypeScript.
 ---
 
 The JavaScript Registry (**JSR**) is a modern package registry for JavaScript
-and TypeScript. JSR works with many runtimes (Node, Deno, browsers, and more)
+and TypeScript. JSR works with many runtimes (Node.js, Deno, browsers, and more)
 and is backwards compatible with npm.
-[Learn more about why we built JSR](/docs/why).
+[Learn more about why we built JSR.](/docs/why)
 
 ## Using JSR packages
 
@@ -42,8 +42,7 @@ camelCase("hello world"); // "helloWorld"
 
 You can find more packages on [jsr.io](https://jsr.io). Each package on the JSR
 site also displays documentation, which is automatically generated from the
-package's source code.
-[Learn more about using JSR packages](/docs/using-packages).
+package's source code. [Learn more about using packages.](/docs/using-packages)
 
 ## Publishing JSR packages
 
@@ -98,4 +97,4 @@ Successfully published @luca/[email protected]
 Visit https://jsr.io/@luca/[email protected] for details
 ```
 
-Learn more about [publishing JSR packages](/docs/publishing-packages).
+[Learn more about publishing packages.](/docs/publishing-packages)

frontend/docs/migrate-x-to-jsr.md

@@ -5,8 +5,9 @@ description:
   guide to learn how.
 ---
 
-> **NOTE:** This guide is for Deno users only. If you are using JSR with Node or
-> in a different runtime environment, this information does not pertain to you.
+> **NOTE:** This guide is for Deno users only. If you are using JSR with Node.js
+> or in a different runtime environment, this information does not pertain to
+> you.
 
 For package authors currently hosting modules on
 [deno.land/x](https://deno.land/x), it should be possible to migrate those

frontend/docs/packages.md

@@ -6,11 +6,11 @@ description: Packages are collections of JavaScript or TypeScript code published
 Packages are the core of JSR. Packages are collections of JavaScript or
 TypeScript code published by an author to the JSR site. Packages can be imported
 by other users using `jsr:` imports.
-[Learn more about using JSR](/docs/using-packages).
+[Learn more about using JSR.](/docs/using-packages)
 
 Packages are contained by scopes. Scopes are collections of packages published
 by an author to the JSR site. Scopes are similar to npm organizations or GitHub
-accounts. [Learn more about scopes](/docs/scopes).
+accounts. [Learn more about scopes.](/docs/scopes)
 
 Packages have a name. Package names are unique within a scope - no two packages
 in the same scope can have the same name. Package names must be between 2 and 20
@@ -43,7 +43,7 @@ repository, one must be an admin of the repository on GitHub.
 
 Linking a GitHub repository also enables tokenless publishing from GitHub
 Actions using OIDC.
-[Learn more about publishing from GitHub Actions](/docs/publishing-packages#publishing-from-github-actions).
+[Learn more about publishing from GitHub Actions.](/docs/publishing-packages#publishing-from-github-actions)
 
 ## Deleting a package
 
@@ -52,18 +52,18 @@ admins can delete a package.
 
 Packages can only be deleted if they have no published versions. If a package
 has published versions, it can not be deleted.
-[Learn more about registry immutability](/docs/immutability).
+[Learn more about registry immutability.](/docs/immutability)
 
 ## Versions
 
 Code in a package is published as a version. A version is a snapshot of the
 package's code at a point in time. Versions are immutable - once a version is
 published, it cannot be changed or deleted. This ensures that packages are
 reliable and that users can trust that a package will not change out from under
-them. [Learn more about registry immutability](/docs/immutability).
+them. [Learn more about registry immutability.](/docs/immutability)
 
 Versions are published using the `jsr publish` or `deno publish` command.
-[Learn more about publishing packages](/docs/publishing-packages).
+[Learn more about publishing packages.](/docs/publishing-packages)
 
 Versions must be valid [SemVer](https://semver.org/) versions. We recommend that
 packages follow semantic versioning policies. These work as follows:

frontend/docs/publishing-packages.md

@@ -5,8 +5,8 @@ description: Learn how to publish packages to JSR.
 
 You can publish most JavaScript and TypeScript code written using ESM modules as
 a JSR package. JSR packages are published to [jsr.io](/), and can be imported
-from **Deno**, **Node**, and other tools.
-[Learn more about using JSR packages](/docs/using-packages).
+from **Deno**, **Node.js**, and other tools.
+[Learn more about using packages.](/docs/using-packages)
 
 Both code written originally to use `package.json`, and code written originally
 for Deno can be published as a JSR package. JSR supports and encourages
@@ -35,16 +35,16 @@ code must follow these rules to be able to be published to JSR.
 - **`node:` built-ins are supported**: You can import Node.js built-ins using
   the `node:` scheme. For example, you can import the `fs` module using
   `import { readFile } from "node:fs";`. If your package has a `package.json`,
-  you can also import Node built-ins with bare specifiers (without the `node:`
-  prefix).
+  you can also import Node.js built-ins with bare specifiers (without the
+  `node:` prefix).
 - **Simple file names**: File names must be Windows and Unix compatible. This
   means that file names cannot contain characters like `*`, `:`, or `?`. You may
   also not have multiple files with the same name, but different casing.
 - **Preferably, no TypeScript "slow types"**: To speed up type checking, support
-  documentation generation, and node compatibility, JSR packages should not use
-  certain TypeScript types in exported functions, classes, or variables. This is
-  enforced by default, but can be opted out of.
-  [Learn more about "slow types"](/docs/about-slow-types).
+  documentation generation, and Node.js compatibility, JSR packages should not
+  use certain TypeScript types in exported functions, classes, or variables.
+  This is enforced by default, but can be opted out of.
+  [Learn more about "slow types."](/docs/about-slow-types)
 - **Valid cross file imports**: All of the relative imports between modules in
   your package must resolve at publish time. The format of supported specifiers
   depends on whether a `package.json` is in use, and is elaborated below.
@@ -125,7 +125,7 @@ import * as express from "npm:express@4";
 You may import JSR packages specified in the `"dependencies"` of a
 `package.json`, ones specified in an import map or `deno.json`, or ones
 specified in source code using `jsr:` specifiers.
-[Learn more about using JSR packages](/docs/using-packages).
+[Learn more about using packages.](/docs/using-packages)
 
 ```json
 // package.json
@@ -143,7 +143,7 @@ import * as encoding from "@std/encoding";
 import { camelCase } from "jsr:@luca/cases@1";
 ```
 
-### Importing Node built-ins
+### Importing Node.js built-ins
 
 You may import Node.js built-ins using the `node:` scheme. If a `package.json`
 is present in your package, you may also omit the `node:` scheme.
@@ -188,7 +188,7 @@ When writing TypeScript, you should ensure that your code does not use "slow
 types" that prevent JSR from generating documentation, generating type
 declarations for the npm compatibility layer, and speeding up type checking for
 consumers of your package.
-[Learn more about "slow types"](/docs/about-slow-types).
+[Learn more about "slow types."](/docs/about-slow-types)
 
 > You may temporarily bypass this restriction by publishing with the
 > `--allow-slow-types` flag. This will cause type checking to be significantly
@@ -213,12 +213,12 @@ JSR properties in their `deno.json` to avoid having to create another file.
 ```
 
 The `name` field is the name of your package, prefixed with a JSR scope.
-[Learn more about scope and package names](#creating-a-scope-and-package).
+[Learn more about scope and package names.](#creating-a-scope-and-package)
 
 The `version` field is the version of your package. This field must be a valid
 [SemVer](https://semver.org/) version. You must increment the version of your
 package every time you publish a new version.
-[Learn more about package versions](/docs/packages#versions).
+[Learn more about package versions.](/docs/packages#versions)
 
 The `exports` field tells JSR which modules should be importable by users of
 your package. The `exports` field can either be specified as a single string, or
@@ -262,7 +262,7 @@ You can also use the `include` and `exclude` options to include and exclude
 files during publishing. If using a `deno.json`, you can use `publish.include`
 and `publish.exclude` to include and exclude files only for publishing, rather
 than for all Deno subcommands.
-[Learn more about ignoring files](#ignoring-files).
+[Learn more about ignoring files.](#ignoring-files)
 
 ## Creating a scope and package
 
@@ -275,15 +275,15 @@ You can create a scope at [jsr.io/new](/new). Scopes names must be between 2 and
 hyphens. You can only create a scope if the name is not already taken. Scope
 names that are very similar to existing scope names -- for example ones that
 only differ by a hyphen -- are prohibited.
-[Learn more about scopes](/docs/scopes).
+[Learn more about scopes.](/docs/scopes)
 
 After you have created a scope, you can create a package in that scope. You can
 create a package at [jsr.io/new](/new). Package names must be between 2 and 20
 characters long, and can only contain lowercase letters, numbers, and hyphens.
 You can only create a package if the name is not already taken. Package names
 that are very similar to existing package names -- for example ones that only
 differ by a hyphen -- are prohibited.
-[Learn more about packages](/docs/packages).
+[Learn more about packages.](/docs/packages)
 
 ## Verifying your package
 
@@ -355,7 +355,7 @@ During publishing, both the JSR CLI and the JSR server will run many checks
 against your package to ensure that it is valid. If any of these checks fail,
 the CLI will output an error message. You must fix these errors before you can
 attempt publishing again.
-[Learn more about troubleshooting publishing errors](/docs/troubleshooting#publishing-errors).
+[Learn more about troubleshooting publishing errors.](/docs/troubleshooting#publishing-errors)
 
 ## Publishing from GitHub Actions
 

frontend/docs/scopes.md

@@ -90,7 +90,7 @@ If you are the last member of a scope, you cannot leave the scope. You can
 
 Scopes can only be deleted if they have no packages. If you want to delete a
 scope, you must first delete all packages in that scope.
-[Learn more about package deletion](/docs/packages#deleting-a-package).
+[Learn more about package deletion.](/docs/packages#deleting-a-package)
 
 Scopes can be deleted by scope admins from the scope settings page.
 
@@ -99,7 +99,7 @@ Scopes can be deleted by scope admins from the scope settings page.
 If you link a package in your scope to a GitHub repository, you can publish
 packages from GitHub Actions without having to configure any secrets or
 authentication.
-[Learn more about publishing from GitHub Actions](/docs/publishing-packages#publishing-from-github-actions).
+[Learn more about publishing from GitHub Actions.](/docs/publishing-packages#publishing-from-github-actions)
 
 Firstly, publishing is permitted only if the GitHub Actions workflow runs in the
 GitHub repository that is linked to the package on JSR.

frontend/docs/scoring.md

@@ -12,7 +12,7 @@ factors from 4 high level categories:
 
 - **Documentation**: The presence of a README file, module documentation, and
   documentation for public functions and types.
-  [Learn more about writing documentation](/docs/writing-docs).
+  [Learn more about writing documentation.](/docs/writing-docs)
 - **Best practices**: Packages should not use
   [slow types](/docs/about-slow-types), and should be published with
   [package provenance](/docs/trust).