Update package-within.Rmd (#1014)

Fixed some typos and grammatical errors in Chapter 5 (Package Within)

package-within.Rmd

@@ -646,7 +646,7 @@ timestamp <- function(time = Sys.time()) {
 ```
 
 These show various methods to limit the scope of our changes to LC_TIME and the timezone.
-A good rule of thumb is to make the scope of such changes as narrow as is possible and practical.
+A good rule of thumb is to make the scope of such changes as narrow as possible and practical.
 The `tz` argument of `format()` is the most surgical way to deal with the timezone, but nothing similar exists for LC_TIME.
 We make the temporary locale modification using the withr package, which provides a very flexible toolkit for temporary state changes.
 This (and `base::on.exit()`) are discussed further in @sec-code-r-landscape.
@@ -659,10 +659,10 @@ If such changes are unavoidable, make sure to reverse them (if possible) or to d
 ## Concluding thoughts
 
 Finally, after several iterations, we have successfully extracted the repetitive data cleaning code for the swimming survey into an R package.
-This example concludes the first part of book and marks the transition into more detailed reference material on specific package components.
+This example concludes the first part of the book and marks the transition into more detailed reference material on specific package components.
 Before we move on, let's review the lessons learned in this chapter.
 
-### Script vs.package
+### Script vs. package
 
 When you first hear that expert R users often put their code into packages, you might wonder exactly what that means.
 Specifically, what happens to your existing R scripts, R Markdown reports, and Shiny apps?
@@ -687,7 +687,7 @@ Once you reach this stage, you're in a great position to take the next step and
 Writing package code is a bit different from writing R scripts and it's natural to feel some discomfort when making this adjustment.
 Here are the most common gotchas that trip many of us up at first:
 
--   Package code requires new ways of working with functions in other packages. The `DESCRIPTION` file is the principle way to declare dependencies; we don't do this via `library(somepackage)`.
+-   Package code requires new ways of working with functions in other packages. The `DESCRIPTION` file is the principal way to declare dependencies; we don't do this via `library(somepackage)`.
 -   If you want data or files to be persistently available, there are package-specific methods of storage and retrieval. You can't just put files in the package and hope for the best.
 -   It's necessary to be explicit about which functions are user-facing and which are internal helpers. By default, functions are not exported for use by others.
 -   A new level of discipline is required to ensure that code runs at the intended time (build time vs. run time) and that there are no unintended side effects.