Docs: “can not” ▶︎ “cannot” (#883)

Can not ➡️ cannot

frontend/docs/about-slow-types.md

@@ -139,7 +139,7 @@ Constants should have explicit type annotations:
 ### Global augmentation
 
 Module augmentation and global augmentation must not be used. This means that
-packages can not use `declare global` to introduce new global variables, or
+packages cannot use `declare global` to introduce new global variables, or
 `declare module` to augment other modules.
 
 Here are some examples of unsupported code:
@@ -343,7 +343,7 @@ are:
 
 ## Ignoring slow types
 
-Due to their nature of affecting _if_ JSR can understand the code, you can not
+Due to their nature of affecting _if_ JSR can understand the code, you cannot
 selectively ignore individual diagnostics for slow types. Slow type diagnostics
 can only be ignored for the entire package. Doing this results in incomplete
 documentation and type declarations for the package, and slower type checking
@@ -367,7 +367,7 @@ adding the following to your `deno.json` configuration file:
 }
 ```
 
-Note that because slow type diagnostics can not be individually ignored, one can
+Note that because slow type diagnostics cannot be individually ignored, one can
 not use an ignore comment like `// deno-lint-ignore no-slow-types` to ignore
 slow type diagnostics.
 

frontend/docs/faq.md

@@ -59,7 +59,7 @@ 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.
+Source code published to JSR cannot be deleted.
 [Learn more about immutability.](/docs/immutability)
 
 You can "yank" a version of a package, which will hide the version from the
@@ -118,7 +118,7 @@ true.** JSR can act on your behalf only to read any resources you have granted
 it access to (your email addresses and public profile information). It cannot
 perform arbitrary actions on your behalf.
 
-JSR can not modify your GitHub account, create repositories, create comments, or
+JSR cannot modify your GitHub account, create repositories, create comments, or
 do anything else that would be considered "acting on your behalf". GitHub
 presents this "Act on your behalf" screen to all GitHub Apps, regardless of what
 permissions they actually request.

frontend/docs/npm-compatibility.md

@@ -52,15 +52,15 @@ import { camelCase } from "@luca/cases";
 The JSR npm compatibility layer is not a perfect replacement for native JSR
 support. There are some limitations:
 
-- You can not use `jsr:` specifiers to import JSR packages.
+- You cannot use `jsr:` specifiers to import JSR packages.
 - Unlike with native JSR imports, you are not directly importing TypeScript
   code. Instead JSR transpiles the TypeScript code to JavaScript before it is
   installed into your `node_modules` directory. This generally means that your
   editor experience will suffer, because "Go to definition" and other features
   will link to transpiled JavaScript code, or to generated `.d.ts` files.
 - Install times will generally be slower than with native JSR support, because
   npm will download files even if they are not used in your project.
-- You can not publish JSR packages using the npm compatibility layer, using
+- You cannot publish JSR packages using the npm compatibility layer, using
   `npm publish`. You can only publish JSR packages using `jsr publish` or
   `deno publish`.
 

frontend/docs/packages.md

@@ -86,7 +86,7 @@ A package can be deleted from the "Settings" tab on the package page. Only scope
 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.
+has published versions, it cannot be deleted.
 [Learn more about registry immutability.](/docs/immutability)
 
 When you have a package that you no longer want to maintain, we recommend
@@ -118,7 +118,7 @@ file before running `jsr publish` or `deno publish`.
 
 ### Yanking versions
 
-Package versions can not be deleted. However, sometimes you may want to prevent
+Package versions cannot be deleted. However, sometimes you may want to prevent
 users from using a specific version of your package, for example because it
 contains a critical bug. In this case you can "yank" the version.
 

frontend/docs/private-registries.md

@@ -75,7 +75,7 @@ the Azure DevOps Artifacts feed.
 
 ### Configuring a JSR upstream with Google Artifact Registry
 
-JSR can not yet be used as an upstream for Google Artifact Registry due to a
+JSR cannot yet be used as an upstream for Google Artifact Registry due to a
 differing layout of package tarball URLs between JSR and the layout that is
 expected by Google Artifact Registry.
 
@@ -84,7 +84,7 @@ Aligning JSRs package tarball URLs with the NPM upstream is being tracked in
 
 ### Configuring a JSR upstream with JFrog Artifactory
 
-JSR can not yet be used as an upstream for JFrog Artifactory due to a differing
+JSR cannot yet be used as an upstream for JFrog Artifactory due to a differing
 layout of package tarball URLs between JSR and the layout that is expected by
 JFrog Artifactory.
 

frontend/docs/scopes.md

@@ -60,7 +60,7 @@ can also see all pending invitations on their
 Admins can change the role of other members. To change the role of a member,
 head to the "Members" tab of your scope, click the dropdown next to the member
 you want to change the role of, and select the new role. The new role will take
-effect immediately. Note that you can not demote the last admin of a scope to a
+effect immediately. Note that you cannot demote the last admin of a scope to a
 member. If you want to demote the last admin of a scope to a member, you must
 first promote another member to an admin. A scope must always have at least one
 admin.