There was a case where a dev made a symlink that worked on some machines and not on others. The issue manifested itself on a machine with `RAILS_ENV=staging` as the had their `config/environments/staging.rb` symlinked to another config file. The behavior was very hard to track down.
Current behavior: If you use a bad symlink in a file, you get no warnings or failures or anything. If you have a bad symlink it just ignores the file as if it didn't exist (`File.exist?` returns false for a bad symlink).
Patch behavior: With this patch when a file is not present we check if a symlink exists. If it does, that indicates there is a bad symlink and we should raise
```
File "config/environments/staging.rb" is a symlink that does not point to a valid file
```
assert [1, 3].includes?(2) fails with unhelpful "Asserting failed" message
assert_includes [1, 3], 2 fails with "Expected [1, 3] to include 2" which makes it easier to debug and more obvious what went wrong
We are planning to remove mocha from our test suite because of
performance problems. To make this possible we should stop require mocha
on ActionSupport::TestCase.
This should not affect applications since users still need to add mocha
to Gemfile and this already load mocha.
Added FIXME notes to place that still need mocha removal
Because of the possibility of lib being unintentionally eager loaded
it's been agreed that we'll leave autoload paths and eager load paths
separate for Rails 4.0.
This reverts commit 0757b3388ffe4f44b60de950d40e18ef05055931.
Conflicts:
railties/CHANGELOG.md
Since the default in Rails 4.0 is to run in 'threadsafe' mode we need
to eager load all of the paths in `autoload_paths` so we alias
`eager_load_paths` to it. This may have unintended consequences if
you have added 'lib' to `autoload_paths` such as loading unneeded
code or code intended only for development and/or test environments.
If this applies to your application you should thoroughly check what
is being eager loaded.
When Rails::Paths::Root's []= is used to replace a path it should persist the previous path's glob. Without passing the glob along we get gnarly bugs when trying to wire up things like engines.
module FooEngine
class Engine < ::Rails::Engine
isolate_namespace FooEngine
config.paths['config/initializers'] = "lib/foo_engine/initializers"
end
end
## Example of behaviour before this commit.
#
# Before the initializer override:
>> FooEngine::Engine.config.paths["config/initializers"].glob
=> "**/*.rb"
# After the initializer override:
>> FooEngine::Engine.config.paths["config/initializers"].glob
=> nil
## Example of behaviour after this commit.
#
# Before the initializer override:
>> FooEngine::Engine.config.paths["config/initializers"].glob
=> "**/*.rb"
# After the initializer override:
>> FooEngine::Engine.config.paths["config/initializers"].glob
=> "**/*.rb"
This reverts commit 6acebb38bc0637bc05c19d87f8767f16ce79189b.
Usage of this feature did not reveal any improvement in existing apps.
Conflicts:
actionpack/lib/action_dispatch/routing/mapper.rb
guides/source/routing.textile
railties/lib/rails/engine.rb
railties/lib/rails/paths.rb
railties/test/paths_test.rb
This feature enables the ability to load an
external routes file from the router via:
draw :filename
External routes files go in +config/routes+. This
feature works in both engines and applications.
* Added :autoload to engines path API and redefine usage to be in sync with 6f83a5036d8a9c3f8ed7;
* Do not autoload code in *lib* for applications (now you need to explicitly require them). This makes an application behave closer to an engine (code in lib is still autoloaded for plugins);
* Always autoload code in app/ for engines and plugins. This makes engines behave closer to an application and should allow us to get rid of the unloadable hack required when controllers inside engines inherit from ApplicationController;
