rails--rails/railties/lib/rails/tasks/dev.rake

# frozen_string_literal: true

require "rails/command"
require "active_support/deprecation"

namespace :dev do
  task cache: :environment do
    ActiveSupport::Deprecation.warn("Using `bin/rake dev:cache` is deprecated and will be removed in Rails 6.1. Use `bin/rails dev:cache` instead.\n")
    Rails::Command.invoke "dev:cache"
  end
end
Adding frozen_string_literal pragma to Railties. 2017-08-14 13:08:09 -04:00			`# frozen_string_literal: true`

Have `bin:rake dev:cache` use the Dev Rails Command under the hood * Call the Rails::Command::DevCommand in the rake task for dev:cache * Add deprecation for using `bin/rake` in favor of `bin/rails` 2018-08-08 14:01:23 -04:00			`require "rails/command"`
			`require "active_support/deprecation"`
Share dev caching implementation between task and server. Lets have the server and the Rake task go through the same ropes, so we can share all the file lookup, adding, and deleting code. 2016-03-14 18:02:25 -04:00
revert dev:cache to rake task, fixes #23410 2016-02-07 17:21:40 -05:00			`namespace :dev do`
Respect config setting when output deprecation notice in rake tasks The rake tasks which became deprecate now does not load the environment. Therefore, even if the application specifies the behavior of deprecating, the message is output to stderr ignoring the specification. It seems that this is not the expected behavior. We should respect the setting even in the rake tasks. 2018-09-01 03:31:15 -04:00			`task cache: :environment do`
Have `bin:rake dev:cache` use the Dev Rails Command under the hood * Call the Rails::Command::DevCommand in the rake task for dev:cache * Add deprecation for using `bin/rake` in favor of `bin/rails` 2018-08-08 14:01:23 -04:00			ActiveSupport::Deprecation.warn("Using `bin/rake dev:cache` is deprecated and will be removed in Rails 6.1. Use `bin/rails dev:cache` instead.\n")
			`Rails::Command.invoke "dev:cache"`
revert dev:cache to rake task, fixes #23410 2016-02-07 17:21:40 -05:00			`end`
			`end`