Fix typos and grammatical issues (#37)

* Fix typos in comments and docs; add typos config for intentional patterns

* Fix grammatical issues in documentation and comments

* Remove _typos.toml

Author: dduugg

CHECKERS.md

@@ -33,7 +33,7 @@ public_path: my/custom/path/
 ### Defining public constants through sigil
 
 > [!WARNING]
-> This way of of defining the public API of a package should be considered WIP. It is not supported by all tooling in the RubyAtScale ecosystem, as @alexevanczuk pointed out in a [comment on the PR](https://github.com/rubyatscale/packwerk-extensions/pull/35#discussion_r1334331797):
+> This way of defining the public API of a package should be considered WIP. It is not supported by all tooling in the RubyAtScale ecosystem, as @alexevanczuk pointed out in a [comment on the PR](https://github.com/rubyatscale/packwerk-extensions/pull/35#discussion_r1334331797):
 >
 > There are a couple of other places that will require changes related to this sigil. Namely, everything that is coupled to the public folder implementation of privacy.
 >
@@ -196,7 +196,7 @@ enforce_visibility: true
 enforcement_globs_ignore:
 - enforcements:
   - privacy
-  - visiblity
+  - visibility
   ignores:
   - "**/*"
   # Enforce incoming privacy and visibility violation references _only_ in `pks/product_services/serv1/**/*`

README.md

@@ -10,7 +10,7 @@ Currently, it ships the following checkers to help improve the boundaries betwee
 - A `dependency` checker requires that a pack specifies packs on which it depends. Cyclic dependencies are not allowed. See [packwerk](https://github.com/Shopify/packwerk)
 - A `privacy` checker that ensures other packages are using your package's public API
 - A `visibility` checker that allows packages to be private except to an explicit group of other packages.
-- A `folder_privacy` checker that allows packages to their sibling packs and parent pack (to be used in an application that uses folder packs)
+- A `folder_privacy` checker that allows packages to be private to their sibling packs and parent pack (to be used in an application that uses folder packs)
 - A `layer` (formerly `architecture`) checker that allows packages to specify their "layer" and requires that each layer only communicate with layers below it.
 
 See [Checkers](CHECKERS.md) for detailed descriptions.

dev/notes.md

@@ -6,7 +6,7 @@
 
 ## Performance
 Although `pks` is intended to be fast, there are ways it can be made a lot faster!
-- Conditional cache usage. For example, implemented as an LSP, pks could always use cache and only bust specific caches (asychronously) when certain events (e.g. file changes) are received.
+- Conditional cache usage. For example, implemented as an LSP, pks could always use cache and only bust specific caches (asynchronously) when certain events (e.g. file changes) are received.
 - By using modified time, we can avoid opening the entire file and parsing it and calculating the md5 hash. It's possible this would not be a meaningful performance improvement.
 
 ### Improved use of references (less cloning)
@@ -41,13 +41,13 @@ time cargo run --profile=release -- --debug --project-root=../your_app check
 # Packwerk Implementation Considerations
 - See `EXPERIMENTAL_PARSER_USAGE.md` for more info
 - Packwerk considers a definition to be a reference. I explored removing this in this branch: https://github.com/alexevanczuk/packs/pull/44
-  - This results in a diff in violations, because if a class opens up a module defined by another class, its considered to be a reference to that other class.
-  - I think this is actually a bug in packwerk, since a definition is not really a reference. Even though monkey patching / opening up other moduels is not great, we should surface that information through a different mechanism (such as allowing packs to have a monkey patches violation)
+  - This results in a diff in violations, because if a class opens up a module defined by another class, it's considered to be a reference to that other class.
+  - I think this is actually a bug in packwerk, since a definition is not really a reference. Even though monkey patching / opening up other modules is not great, we should surface that information through a different mechanism (such as allowing packs to have a monkey patches violation)
 
 # Abandoned Performance Improvement Attempts
 - In https://github.com/alexevanczuk/packs/pull/37, I looked into getting the constants *as* we are walking the directory. However, I found that this was hardly much more performant than the current implementation, and it was much more complex. I abandoned this approach in favor of caching the resolver and other performance improvements.
-- We could consider caching the RESOLVED references in a file, which would allow us to potentially skip generating the constant resolver and resolving all of the unresolved constants. This makes cache invalidation more complex though, and the flamegraph shows that most of the time is spent opening files, not resolving constants. Furthermore, the experimental constant resolver resolves constant much more quickly.
-- In https://github.com/alexevanczuk/packs/pull/98, I looked into having a single file as the cache rather than one cache file per code file. This turned out to be a *lot* slower, and I think the reason is that serialization and deserialization happens does not happen in parallel with one large file, where it does happen with lots of tiny files.
+- We could consider caching the RESOLVED references in a file, which would allow us to potentially skip generating the constant resolver and resolving all of the unresolved constants. This makes cache invalidation more complex though, and the flamegraph shows that most of the time is spent opening files, not resolving constants. Furthermore, the experimental constant resolver resolves constants much more quickly.
+- In https://github.com/alexevanczuk/packs/pull/98, I looked into having a single file as the cache rather than one cache file per code file. This turned out to be a *lot* slower, and I think the reason is that serialization and deserialization does not happen in parallel with one large file, where it does happen with lots of tiny files.
 - In https://github.com/alexevanczuk/packs/pull/99, I began (very initial stages) of integrating with SQLite to hopefully provide a faster cache. It's not clear to me if this would actually provide much of a performance improvement. It might still be worth exploring, but for now abandoning it since it introduces a lot of complexity.
 
 # Modular Architecture

src/packs/checker/reference.rs

@@ -122,7 +122,7 @@ impl Reference {
         } else {
             let defining_pack_name = None;
             let relative_defining_file = None;
-            // Contant name is not known, so we'll just use the unresolved name for now
+            // Constant name is not known, so we'll just use the unresolved name for now
             let constant_name = unresolved_reference.name.clone();
 
             Ok(vec![Reference {

src/packs/package_todo.rs

@@ -135,7 +135,7 @@ pub fn write_violations_to_disk(
     violations: HashSet<Violation>,
 ) {
     debug!("Starting writing violations to disk");
-    // First we need to group the violations by the repsonsible pack, which today is always the referencing pack
+    // First we need to group the violations by the responsible pack, which today is always the referencing pack
     // Later if we change where a violation shows up, we should delegate to the checker
     // to decide what pack it should be in.
     let mut violations_by_responsible_pack: HashMap<String, Vec<Violation>> =

src/packs/parsing/ruby/experimental/constant_resolver.rs

@@ -118,7 +118,7 @@ impl ExperimentalConstantResolver {
     //
     // The `current_namespace_path` here is: ['Foo', 'Bar', 'Baz']
     // The `const_name` here is: `Boo`
-    // Ruby constant resolution rules dictate that `Boo` coudl refer to any of the following,
+    // Ruby constant resolution rules dictate that `Boo` could refer to any of the following,
     // in this specific order:
     //
     // ::Foo::Bar::Baz::Boo

src/packs/parsing/ruby/packwerk/parser.rs

@@ -292,7 +292,7 @@ pub(crate) fn process_from_contents(
                         == r.location.start_row
                         && location.start_col == r.location.start_col;
                     // In lib/packwerk/parsed_constant_definitions.rb, we don't count references when the reference is in the same place as the definition
-                    // This is an idiosyncracy we are porting over here for behavioral alignment, although we might be doing some unnecessary work.
+                    // This is an idiosyncrasy we are porting over here for behavioral alignment, although we might be doing some unnecessary work.
                     should_ignore_local_reference = !reference_is_definition;
                 }
             }

src/packs/parsing/ruby/zeitwerk/constant_resolver.rs

@@ -138,7 +138,7 @@ impl ZeitwerkConstantResolver {
     //
     // The `current_namespace_path` here is: ['Foo', 'Bar', 'Baz']
     // The `const_name` here is: `Boo`
-    // Ruby constant resolution rules dictate that `Boo` coudl refer to any of the following,
+    // Ruby constant resolution rules dictate that `Boo` could refer to any of the following,
     // in this specific order:
     //
     // ::Foo::Bar::Baz::Boo
@@ -162,7 +162,7 @@ impl ZeitwerkConstantResolver {
         if let Some(constant) =
             self.constant_for_fully_qualified_name(&fully_qualified_name_guess)
         {
-            // Since the ContantResolver might say that some constant Foo::Bar::Baz is defined in Foo::Bar,
+            // Since the ConstantResolver might say that some constant Foo::Bar::Baz is defined in Foo::Bar,
             // we want to return a ConstantDefinition that has the fully qualified name of the constant we're looking for.
             // In this case, we want to return a ConstantDefinition with the fully qualified name of Foo::Bar::Baz
             // even though the ConstantDefinition we found has the fully qualified name of Foo::Bar