… help These options are not actually available. Thanks @soutaro for letting me aware of this.
Before: namespace :foo do namespace :bar do get 'baz/index' end end After: namespace :foo do namespace :bar do get 'baz/index' end end
This make the config/initializers run before the railties are loaded what can break some configurations.
Previously, running `rails new` would not print any of the output from `bundle install` until all the gems had finished installing. This made it look like the generator was hanging at the `bundle install` step. This commit switches to using `system` so that the bundle command can output as it needs to. This has the added benefit of including output bundler produces on standard error, which the previous code ignored since backticks only capture standard out. This is not a big deal right now since bundler does not currently print errors to standard error, but that may change in the future (see: bundler/bundler#3353).
…re [ci skip]
…n-gitignore-template" This reverts commit b824dfd, reversing changes made to 265dcb7. Our general recommendation is to check in the lock file in the repository. This make possible to developers and contributors of a plugin always run their tests against a working set of dependencies. Also, bisect is a lot easier, specially if you have git dependencies in your Gemfile.
README.rdoc was generated to support the doc:app task. Now that this task is gone we can switch to Markdown, which is nowadays a better default.
This patch removes the tasks doc:app, doc:rails, and doc:guides. In our experience applications do not generate APIs using doc:app. Methods may be certainly documented for maintainers, annotated with YARD tags, etc. but that is intended to be read with the source code, not in a separate website. Then, teams also have typically selected topics written down in Markdown files, or in a GitHub wiki... that kind of thing. If a team absolutely needs to generate application documentation for internal purposes, they can still easily write their own task. Regarding doc:rails and doc:guides, we live in 2015. We are used to go to online docs all the time. If you really want access to the API offline RubyGems generates it for every Rails component unless you tell it not to, and you can checkout the Rails source code to read the guides as Markdown, or download them for a Kindle reader. All in all, maintaining this code does not seem to be worthwhile anymore. As a consequence of this, guides (+3 MB uncompressed) won't be distributed with the rails gem anymore. Of course, guides and API are going to be still part of releases, since documentation is maintained alongside code and tests. Also, time permitting, this will allow us to experiment with novel ways to generate documentation in the Rails docs server, since right now we were constrained by being able to generate them in the user's environment.
Thor isn't very discerning over whether some content is present when passed to `inject_into_file`, e.g. a commented out route is detected as being present. So to prevent people scratching their heads as to why a route hasn't appeared it's better to fall on the side of having duplicate routes.
When there is a single scaffold in the routes.rb with no other lines then revoking/destroying it will create a routes.rb file with a syntax error. This is because the sentinel for the Thor `route` action didn't include the newline but the logged route code did. The fix is to add the newline to the sentinel and remove it from the the logged route code. Fixes #15913.
It was not possible to create a new gem with a hyphenated name via the `rails plugin new` generator. The naming guide of rubygems clearly says dashes should be used for gems that extend other gems. http://guides.rubygems.org/name-your-gem/