| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
This reverts commit 3420a14590c0e6915d8b6c242887f74adb4120f9, reversing
changes made to afb66a5a598ce4ac74ad84b125a5abf046dcf5aa.
|
| |
|
|
|
|
|
|
| |
".. with __dir__ we can restore order in the Universe." - by @fxn
Related to 5b8738c2df003a96f0e490c43559747618d10f5f
|
|
|
|
| |
(I personally prefer writing one string in one line no matter how long it is, though)
|
|
|
|
| |
Actually, private methods cannot be called with `self.`, so it's not just redundant, it's a bad habit in Ruby
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
Style/SpaceBeforeBlockBraces
Style/SpaceInsideBlockBraces
Style/SpaceInsideHashLiteralBraces
Fix all violations in the repository.
|
|
|
|
|
|
|
|
|
| |
A few have been left for aesthetic reasons, but have made a pass
and removed most of them.
Note that if the method `foo` returns an array, `foo << 1`
is a regular push, nothing to do with assignments, so
no self required.
|
| |
|
|
|
|
|
| |
The current code base is not uniform. After some discussion,
we have chosen to go with double quotes by default.
|
| |
|
|
|
|
| |
Various grammar corrections and wrap to 80 characters.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
The generators entry point file is rails/generators so we need to make
sure uers will be able to use the generators when requiring that file.
Fixes #12802
|
|\
| |
| | |
Fix railties build
|
| |
| |
| |
| |
| | |
rails/generators should not load rails/generators/base since the
latter is loading it.
|
|/
|
|
| |
Same as 4d4ff531b8807ee88a3fc46875c7e76f613956fb
|
|
|
|
|
| |
AppPreparer doesn't actually prepare applications, it scrubs ARGV.
Let's also get the class under test while we're at it
|
|
|
|
|
|
|
| |
The defaults hash isn't used unless the +class_options+ hash has a
particular key, so we don't need to compute it unless this is true.
Also moving some code for extracting a module into its own method.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
by Active Support)
Selecting which key extensions to include in active_support/rails
made apparent the systematic usage of Object#in? in the code base.
After some discussion in
https://github.com/rails/rails/commit/5ea6b0df9a36d033f21b52049426257a4637028d
we decided to remove it and use plain Ruby, which seems enough
for this particular idiom.
In this commit the refactor has been made case by case. Sometimes
include? is the natural alternative, others a simple || is the
way you actually spell the condition in your head, others a case
statement seems more appropriate. I have chosen the one I liked
the most in each case.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
In case `source_roout` is not set, `default_source_root` is used,
which includes also `templates` directory. If there is no `templates`
directory, `default_source_root` is not available and USAGE will not
be displayed. USAGE should be also checked based on default
directory excluding `templates`.
|
|
|
|
|
|
| |
It is usually useful to be able to hide a generator when running rails
generate command. Such generators might be used only to dry up
generators code and shouldn't be available to end users.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
After a long list of discussion about the performance problem from using varargs and the reason that we can't find a great pair for it, it would be best to remove support for it for now.
It will come back if we can find a good pair for it. For now, Bon Voyage, `#among?`.
|
|
|
|
| |
suggestion!
|
|
|
|
| |
There're a lot of places in Rails source code which make a lot of sense to switching to Object#in? or Object#either? instead of using [].include?.
|
|
|
|
|
|
| |
state:resolved]
Signed-off-by: Santiago Pastorino <santiago@wyeworks.com>
|
|
|
|
| |
This will make `rails g rspec:install --help` shows "rails generate rspec:install [options]" and not "rails generate install [options]"
|
|
|
|
| |
's/[ \t]*$//' -i {} \;)
|
| |
|
|
|
|
|
|
| |
--dev` in the "Thor is not avalable" message. [#4915 state:resolved]
Signed-off-by: José Valim <jose.valim@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If you have existing Metals, you have a few options:
* if your metal behaves like a middleware, add it to the
middleware stack via config.middleware.use. You can use
methods on the middleware stack to control exactly where
it should go
* if it behaves like a Rack endpoint, you can link to it
in the router. This will result in more optimal routing
time, and allows you to remove code in your endpoint
that matches specific URLs in favor of the more powerful
handling in the router itself.
For the future, you can use ActionController::Metal to get
a very fast controller with the ability to opt-in to specific
controller features without paying the penalty of the full
controller stack.
Since Rails 3 is closer to Rack, the Metal abstraction is
no longer needed.
|
| |
|
|
|
|
| |
former since it's less obstrusive.
|