swift2nix post: Fix spelling and grow dictionary

1 files changed, 5 insertions, 5 deletions

diff --git a/_posts/2020-10-05-swift2nix-run-swift-inside-nix-builds.md b/_posts/2020-10-05-swift2nix-run-swift-inside-nix-builds.md
index 3173165..e2368ad 100644
--- a/_posts/2020-10-05-swift2nix-run-swift-inside-nix-builds.md
+++ b/_posts/2020-10-05-swift2nix-run-swift-inside-nix-builds.md
@@ -82,7 +82,7 @@ part is important: it should be data, not code, otherwise you're back in the
 same problem, just like lockfiles are just data. Those work in any language, and
 tools can cooperate happily.
 
-There's no need for this declarative expectation to be standartized, or be made
+There's no need for this declarative expectation to be standardized, or be made
 compatible across languages. That would lead to a poor format that no package
 manager really likes. Instead, If every package manager could say out loud what
 it wants to see exactly, than more tools like swift2nix could exist, and they
@@ -101,7 +101,7 @@ usually have fuzzy boundaries and tight coupling between:
    version;
 2. generating a lockfile with the exact pinned versions;
 3. downloading the dependencies present on the lockfile into some local cache;
-4. arranging the dependencies from the cache in a meaniful way for itself inside
+4. arranging the dependencies from the cache in a meaningful way for itself inside
    the project;
 5. work using the dependencies while *assuming* that step 4 was done.
 
@@ -123,7 +123,7 @@ Instead a much saner approach could be:
 
 The point is just making what the package manager requires visible to the
 outside world via some declarative data. If this data wasn't provided, it can
-move on to doing its own automagic things.
+move on to doing its own automatic things.
 
 By making the expectation explicit and public, one can plug tools *à la carte*
 if desired, but doesn't prevent the default code path of doing things the exact
@@ -138,7 +138,7 @@ inside Nix".
 
 The avoidance of an "easy" interface that I mentioned above comes from me
 fighting with some of the "\*2nix" tools much like I have to fight with package
-managers: I don't want to offload all build responsabilities to the "*2nix"
+managers: I don't want to offload all build responsibilities to the "*2nix"
 tool, I just want to let it download some of the dependencies and get out of the
 way. I want to stick with `npm test` or `cargo build`, and Nix should only
 provide the environment.
@@ -161,7 +161,7 @@ and reproducibility that Nix provides. It is even less brittle: any changes to
 how NPM runs some things will be future-compatible, since node2nix isn't trying
 to replicate what NPM does, or fiddling with NPM's internal.
 
-**A "*2nix" tool should build the environment, preferebly from the lockfile
+**A "*2nix" tool should build the environment, preferably from the lockfile
 directly and offload everything else to the package manager**. Everything else
 is just nice-to-have.