Update classic_to_zeitwerk_howto.md

Some typos were fixed on the Zeitwerk migration guide.
This commit is contained in:
Aitor García Rey 2023-10-17 18:54:58 +02:00 committed by GitHub
parent ae6fa7a048
commit 4a3e51a840
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 4 additions and 4 deletions

View File

@ -133,7 +133,7 @@ All is good!
There can be additional output depending on the application configuration, but the last "All is good!" is what you are looking for.
If the double-check explained in the previous section determined actually there have to be some custom autoload paths outside the eager load paths, the task will detect and warn about them. However, if the test suite loads those files successfully, you're good.
If the double-check explained in the previous section determined that there have to be some custom autoload paths outside the eager load paths, the task will detect and warn about them. However, if the test suite loads those files successfully, you're good.
Now, if there's any file that does not define the expected constant, the task will tell you. It does so one file at a time, because if it moved on, the failure loading one file could cascade into other failures unrelated to the check we want to run and the error report would be confusing.
@ -147,7 +147,7 @@ Hold on, I am eager loading the application.
expected file app/models/vat.rb to define constant Vat
```
VAT is an European tax. The file `app/models/vat.rb` defines `VAT` but the autoloader expects `Vat`, why?
VAT is a European tax. The file `app/models/vat.rb` defines `VAT` but the autoloader expects `Vat`, why?
### Acronyms
@ -198,7 +198,7 @@ By default, `app/models/concerns` belongs to the autoload paths and therefore it
If your application uses `Concerns` as namespace, you have two options:
1. Remove the `Concerns` namespace from those classes and modules and update client code.
1. Remove the `Concerns` namespace from those classes and modules and update the client code.
2. Leave things as they are by removing `app/models/concerns` from the autoload paths:
```ruby
@ -455,7 +455,7 @@ Delete any `require` Calls
In my experience, projects generally do not do this. But I've seen a couple, and have heard of a few others.
In Rails application you use `require` exclusively to load code from `lib` or from 3rd party like gem dependencies or the standard library. **Never load autoloadable application code with `require`**. See why this was a bad idea already in `classic` [here](https://guides.rubyonrails.org/v6.1/autoloading_and_reloading_constants_classic_mode.html#autoloading-and-require).
In a Rails application you use `require` exclusively to load code from `lib` or from 3rd party like gem dependencies or the standard library. **Never load autoloadable application code with `require`**. See why this was a bad idea already in `classic` [here](https://guides.rubyonrails.org/v6.1/autoloading_and_reloading_constants_classic_mode.html#autoloading-and-require).
```ruby
require "nokogiri" # GOOD