This change swaps the CommonJS require() syntax in the Webpacker
application.js pack template file and in documentation examples with ES
module import syntax.
Benefits of this change include:
Provides continuity with the larger frontend community: Arguably, one of
the main draws in adopting Webpacker is its integration with Babel to
support ES module syntax. For a fresh Rails install with Webpacker, the
application.js file will be the first impression most Rails developers
have with webpack and Webpacker. Most of the recent documentation and
examples they will find online for using other libraries will be based
on ES module syntax.
Reduces confusion: Developers commonly add ES imports to their
application.js pack, typically by following online examples, which means
mixing require() and import statements in a single file. This leads to
confusion and unnecessary friction about differences between require()
and import.
Embraces browser-friendliness: The ES module syntax forward-looking and
is meant to be supported in browsers. On the other hand, require()
syntax is synchronous by design and not browser-supported as CommonJS
originally was adopted in Node.js for server-side JavaScript. That
webpack supports require() syntax is merely a convenience.
Encourages best practices regarding optimization: webpack can statically
analyze ES modules and "tree-shake", i.e., strip out unused exports from
the final build (given certain conditions are met, including
`sideEffects: false` designation in package.json).
If an assertion is inside a method stub, it may never be evaluated.
This is particularly problematic when asserting a method is called a
non-zero number of times.
This commit moves such assertions outside their method stubs.
Follow up to c07dff72278fb7f2a3c4c71212a0773a2b25c790.
Actually it is not the cop's fault, but we mistakenly use `^`, `$`, and
`\Z` in much places, the cop doesn't correct those conservatively.
I've checked all those usage and replaced all safe ones.
Silence Rake task backtraces, similar to Rails::BacktraceCleaner.
Application lines are preserved, but all other lines are hidden.
This also affects unrecognized tasks, causing the backtrace to be hidden
entirely. Closes#39524.
Co-authored-by: Petrik <petrik@deheus.net>
This test was incorrect. `primary` was winning for the schema cache load
but when you boot an application it's actually the first configuration
that wins (in a multi db app).
The test didn't catch this because I forgot to add a migrations_paths to
the configuration.
We updated the schema cache loader railtie as well because any
application that didn't have a `primary` config would not be able to use
the schema cache. Originally we thought we'd enforce a `primary`
configuration but no longer feel that's correct. It's simpler to say
that the first wins in a 3-tier rather than implementing a solution to
require `primary` and / or allow aliases.
Co-authored-by: John Crepezzi <john.crepezzi@gmail.com>
Co-authored-by: John Hawthorn <john@hawthorn.email>
Applications may not have a primary configuration so we should not
assume there is one. In both these cases we can get the right connection
without that.
For the databases.rake file we want to re-establish a connection for the
environment we're in. The first config defined under an environment for
a multi-db app will win. This is already the case on application boot so
we should be consistent.
For the info.rb file we already have a connection so we can lookup the
adapter from the connection's db_config. If a primary hadn't existed
this would have thrown an exception.
Followup to https://github.com/rails/rails/pull/39535 which removed the
assumption there was a primary config from the schema cache load
railtie.
Co-authored-by: John Crepezzi <john.crepezzi@gmail.com>
Generators generate things, but what is meant by 'Stubbing out' might
confuse beginners and non-native English speakers.
While generated tests are stubs that should have an implementation, a
generated model is a valid model that doesn't require any changes.
details_cache_key already references Template::Types.symbols and view
resolvers cache based on default_formats and other values. This
previously wasn't an issue because no views had been looked up before
this was set. Now that we are building a regex from the values of
Template::Types.symbols we need to clear cache after changing this
setting.
Errors *should* output their stack. Somehow these tests were passing
before. This clarifies all states (skip/fail/error) and works against
@tenderlove's patch.
Before #39304 was merged, backtraces would look like this:
```
$ be ruby -I lib:test test/controller/request_forgery_protection_test.rb -n test_ignores_trailing_slash_during_generation
Run options: -n test_ignores_trailing_slash_during_generation --seed 22205
E
Error:
PerFormTokensControllerTest#test_ignores_trailing_slash_during_generation:
NoMethodError: undefined method `have_cookie_jar?' for #<Object:0x00007f9ce19b9620>
/Users/aaron/git/rails/actionpack/lib/action_controller/test_case.rb:522:in `ensure in process'
/Users/aaron/git/rails/actionpack/lib/action_controller/test_case.rb:542:in `process'
/Users/aaron/git/rails/actionpack/lib/action_controller/test_case.rb:395:in `get'
test/controller/request_forgery_protection_test.rb:1005:in `test_ignores_trailing_slash_during_generation'
rails test test/controller/request_forgery_protection_test.rb:1004
Finished in 0.213230s, 4.6898 runs/s, 0.0000 assertions/s.
1 runs, 0 assertions, 0 failures, 1 errors, 0 skips
```
After #39304 was merged they look like this:
```
$ be ruby -I lib:test test/controller/request_forgery_protection_test.rb -n test_ignores_trailing_slash_during_generation
Run options: -n test_ignores_trailing_slash_during_generation --seed 62892
E
Error:
PerFormTokensControllerTest#test_ignores_trailing_slash_during_generation:
NoMethodError: undefined method `have_cookie_jar?' for #<Object:0x00007fa6d60193c8>
rails test test/controller/request_forgery_protection_test.rb:1004
Finished in 0.211953s, 4.7180 runs/s, 0.0000 assertions/s.
1 runs, 0 assertions, 0 failures, 1 errors, 0 skips
```
This patch reverts the part of #39304 that removes the backtrace.
- Add the configuration option for annotating templates with file names to the generated app.
- Add `annotate_rendered_view_with_filenames` option to configuring guide.
* Add default ENV variable option with BACKTRACE to turn off backtrace cleaning when debugging framework code
* Use runner as the example
Although I think we should consider dropping -b in tests and just relying on this more general option for sidestepping the backtrace cleaner.
I'm not sure about this one. The gist is, minitest's
UnexpectedError#message includes a backtrace but the reporter tests
here expect there not to be one in inline output.
Personally, I think that's wrong as it removes information you'd want
to debug, but this might be a philosophical difference with the rails
test ethos... or it might just be aesthetic.
I am happy to back out this change and fix the tests if you'd rather.
