Spelling (phoenixframework#4909)

Signed-off-by: Josh Soref <[email protected]>

Earthfile

@@ -87,7 +87,7 @@ npm:
     FROM node:12-alpine3.12
     WORKDIR /src
     RUN mkdir assets
-    # Copy package.json + lockfile separatelly to improve caching (JS changes don't trigger `npm install` anymore)
+    # Copy package.json + lockfile separately to improve caching (JS changes don't trigger `npm install` anymore)
     COPY assets/package* assets
     WORKDIR assets
     RUN npm install

assets/js/phoenix/socket.js

@@ -46,7 +46,7 @@ import Timer from "./timer"
  *
  * Defaults `DEFAULT_TIMEOUT`
  * @param {number} [opts.heartbeatIntervalMs] - The millisec interval to send a heartbeat message
- * @param {number} [opts.reconnectAfterMs] - The optional function that returns the millsec
+ * @param {number} [opts.reconnectAfterMs] - The optional function that returns the millisec
  * socket reconnect interval.
  *
  * Defaults to stepped backoff of:
@@ -57,7 +57,7 @@ import Timer from "./timer"
  * }
  * ````
  *
- * @param {number} [opts.rejoinAfterMs] - The optional function that returns the millsec
+ * @param {number} [opts.rejoinAfterMs] - The optional function that returns the millisec
  * rejoin interval for individual channels.
  *
  * ```javascript
@@ -181,7 +181,7 @@ export default class Socket {
   protocol(){ return location.protocol.match(/^https/) ? "wss" : "ws" }
 
   /**
-   * The fully qualifed socket url
+   * The fully qualified socket url
    *
    * @returns {string}
    */

assets/test/channel_test.js

@@ -42,7 +42,7 @@ describe("with transport", function(){
       assert.deepEqual(channel.pushBuffer, [])
     })
 
-    it("sets up joinPush objec with literal params", function(){
+    it("sets up joinPush object with literal params", function(){
       channel = new Channel("topic", {one: "two"}, socket)
       const joinPush = channel.joinPush
 
@@ -52,7 +52,7 @@ describe("with transport", function(){
       assert.equal(joinPush.timeout, 1234)
     })
 
-    it("sets up joinPush objec with closure params", function(){
+    it("sets up joinPush object with closure params", function(){
       channel = new Channel("topic", function(){ return ({one: "two"}) }, socket)
       const joinPush = channel.joinPush
 
@@ -142,7 +142,7 @@ describe("with transport", function(){
       assert.equal(joinPush.timeout, newTimeout)
     })
 
-    it("leaves existings duplicate topic on new join", function(done){
+    it("leaves existing duplicate topic on new join", function(done){
       channel.join()
         .receive("ok", () => {
           let newChannel = socket.channel("topic")
@@ -594,7 +594,7 @@ describe("with transport", function(){
       assert.equal(channel.state, "errored")
     })
 
-    it("does not trigger redudant errors during backoff", function(){
+    it("does not trigger redundant errors during backoff", function(){
       const spy = sinon.stub(joinPush, "send")
 
       assert.equal(spy.callCount, 0)

guides/asset_management.md

@@ -84,7 +84,7 @@ $ yarn add --dev esbuild
 $ yarn add ../deps/phoenix ../deps/phoenix_html ../deps/phoenix_live_view
 ```
 
-Next, add a custom Javascript build script. We'll call the example `assets/build.js`:
+Next, add a custom JavaScript build script. We'll call the example `assets/build.js`:
 
 ```js
 const esbuild = require('esbuild')

guides/contexts.md

@@ -904,7 +904,7 @@ Request: GET /cart
        ...
 ```
 
-It's working! Kind of. If we follow the logs, we see our POST to the `/cart_items` path. Next, we can see our `ShoppingCart.add_item_to_cart` function successfully inserted a row into the `cart_items` table, and then we issued a redirect to `/cart`. Before our error, we also see a query to the `carts` table, which means we're fetching the current user's cart. So far so good. We know our `CartItem` controller and new `ShoppingCart` context functions are doing their jobs, but we've hit our next unimplemented feature when the router attempts to dispatch to a non-existent cart controller. Let's create the cart controller, view, and template to display and manage user carts.
+It's working! Kind of. If we follow the logs, we see our POST to the `/cart_items` path. Next, we can see our `ShoppingCart.add_item_to_cart` function successfully inserted a row into the `cart_items` table, and then we issued a redirect to `/cart`. Before our error, we also see a query to the `carts` table, which means we're fetching the current user's cart. So far so good. We know our `CartItem` controller and new `ShoppingCart` context functions are doing their jobs, but we've hit our next unimplemented feature when the router attempts to dispatch to a nonexistent cart controller. Let's create the cart controller, view, and template to display and manage user carts.
 
 Create a new file at `lib/hello_web/controllers/cart_controller.ex` and key this in:
 

guides/routing.md

@@ -146,7 +146,7 @@ The `Phoenix.Router.resources/4` macro describes additional options for customiz
 
 ## Verified Routes
 
-Phoenix includes `Phoenix.VerifiedRoutes` module which provides compile-time checks of router paths against your router by usign the `~p` sigil. For example, you can write paths in controllers, tests, and templates and the compile will make sure those actually match routes defined in your router.
+Phoenix includes `Phoenix.VerifiedRoutes` module which provides compile-time checks of router paths against your router by using the `~p` sigil. For example, you can write paths in controllers, tests, and templates and the compile will make sure those actually match routes defined in your router.
 
 Let's see it in action. Run `iex -S mix` at the root of the project. We'll define a throwaway example module that builds a couple `~p` route paths.
 
@@ -239,7 +239,7 @@ post_id = 17
 "/users/42/posts/17"
 ```
 
-Verified routes also support the `Phoenix.Param` protocol, but we don't need to concern ourselves with elixir protocols just yet. Just know that once we start building our application with structs like `%User{}` and `%Post{}`, we'll be able to interpolate those datastructures directly into our `~p` paths and phoenix will pluck out the correct fields to use in the route.
+Verified routes also support the `Phoenix.Param` protocol, but we don't need to concern ourselves with elixir protocols just yet. Just know that once we start building our application with structs like `%User{}` and `%Post{}`, we'll be able to interpolate those data structures directly into our `~p` paths and phoenix will pluck out the correct fields to use in the route.
 
 ```elixir
 ~p"/users/#{user}/#{post}"
@@ -540,7 +540,7 @@ Note that pipelines themselves are plugs, so we can plug a pipeline inside anoth
 
 In Phoenix, we tend to define several pipelines, that provide specific functionality. For example, the `:browser` and `:api` pipelines are meant to be accessed by specific clients, browsers and http clients respectively.
 
-Perhaps more importantly, it is also very common to define pipelines specific to authentication and authorization. For example, you might have a pipeline that requires all users are authenticated. Another pipeline may enforce only admin users can acess certain routes.
+Perhaps more importantly, it is also very common to define pipelines specific to authentication and authorization. For example, you might have a pipeline that requires all users are authenticated. Another pipeline may enforce only admin users can access certain routes.
 
 Once your pipelines are defined, you reuse the pipelines in the desired scopes, grouping your routes around their pipelines. For example, going back to our reviews example. Let's say anyone can read a review, but only authenticated users can create them. Your routes could look like this:
 

lib/phoenix/controller.ex

@@ -871,7 +871,7 @@ defmodule Phoenix.Controller do
   Puts the URL or `%URI{}` to be used for the static url generation.
 
   Using this function on a `%Plug.Conn{}` struct tells `static_url/2` to use
-  the given information for URL generation instead of the the `%Plug.Conn{}`'s
+  the given information for URL generation instead of the `%Plug.Conn{}`'s
   endpoint configuration (much like `put_router_url/2` but for static URLs).
   """
   def put_static_url(conn, %URI{} = uri) do

lib/phoenix/router.ex

@@ -273,7 +273,7 @@ defmodule Phoenix.Router do
   Perhaps more importantly, it is also very common to define pipelines specific
   to authentication and authorization. For example, you might have a pipeline
   that requires all users are authenticated. Another pipeline may enforce only
-  admin users can acess certain routes.
+  admin users can access certain routes.
 
   Once your pipelines are defined, you reuse the pipelines in the desired
   scopes, grouping your routes around their pipelines. For example, imagine

lib/phoenix/socket/transport.ex

@@ -31,7 +31,7 @@ defmodule Phoenix.Socket.Transport do
 
   Whenever the transport receives a new connection, it should invoke
   the `c:connect/1` callback with a map of metadata. Different sockets
-  may require different metadatas.
+  may require different metadata.
 
   If the connection is accepted, the transport can move the connection
   to another process, if so desires, or keep using the same process. The

lib/phoenix/verified_routes.ex

@@ -71,7 +71,7 @@ defmodule Phoenix.VerifiedRoutes do
       - `Phoenix.Controller.put_router_url/2` is used to override the endpoint's URL
       - `Phoenix.Controller.put_static_url/2` is used to override the endpoint's static URL
 
-    * When the Router module differs from the the one passed to `use Phoenix.VerifiedRoutes`,
+    * When the Router module differs from the one passed to `use Phoenix.VerifiedRoutes`,
       such as library code, or application code that relies on multiple routers. In such cases,
       the router module can be provided explicitly to `path/3` and `url/3`.
 
@@ -97,7 +97,7 @@ defmodule Phoenix.VerifiedRoutes do
   the `mix compile` task. For the following will show all warnings the compiler
   has previously encountered when compiling the current application code:
 
-      $ mix compile --all-warnigns
+      $ mix compile --all-warnings
 
   *Note: Elixir >= 1.14.0 is required for comprehensive warnings. Older versions
   will compile properly, but no warnings will be issued.

test/mix/tasks/phx.gen.html_test.exs

@@ -224,7 +224,7 @@ defmodule Mix.Tasks.Phx.Gen.HtmlTest do
     end
   end
 
-  test "with --web namespace generates namedspaced web modules and directories", config do
+  test "with --web namespace generates namespaced web modules and directories", config do
     in_tmp_project config.test, fn ->
       Gen.Html.run(~w(Blog Post posts title:string --web Blog))
 

test/mix/tasks/phx.gen.json_test.exs

@@ -156,7 +156,7 @@ defmodule Mix.Tasks.Phx.Gen.JsonTest do
     end
   end
 
-  test "with json --web namespace generates namedspaced web modules and directories", config do
+  test "with json --web namespace generates namespaced web modules and directories", config do
     in_tmp_project config.test, fn ->
       Gen.Json.run(~w(Blog Post posts title:string --web Blog))
 

test/phoenix/verified_routes_test.exs

@@ -176,7 +176,7 @@ defmodule Phoenix.VerifiedRoutesTest do
     end
   end
 
-  test "~p raises on dynamic dynamic interpolation" do
+  test "~p raises on dynamic interpolation" do
     msg = ~S|a dynamic ~p interpolation must follow a static segment, got: "/posts/#{1}#{2}"|
 
     assert_raise ArgumentError, msg, fn ->