Usage of the lifecycle package
Use lifecycle to document the status of your exported functions and arguments. It provides a standard way to describe lifecycle stage in the documentation, and tools to encourage users away from deprecated functions.
Stages
The lifecycle stages for functions1 are summarised in the figure below.
The default development stage is 
. A function is considered stable when the author is sufficiently happy with its interface and behaviour to share it with a large number of users. Stable features come with guarantees. If breaking changes are needed, they will occur gradually, through the deprecation process described below.
The stability of exported functions can be further refined based on the version number of the package they are exported from. In >=1.0.0 packages, the main functionality is considered “done” by the author. Breaking changes and deprecations are unlikely. In sub-1.0.0 packages, some parts of the package (internal backend, external UI, …) still need some work and changes are possible. Stable >=1.0.0 packages are the safest to depend and rely on.
Some packages and functions are published in an 
stage. Experimental features are made available so people can try them out and provide feedback, but the author makes no promises to avoid breaking changes. A deprecation process for breaking changes is not guaranteed (but may still happen if sufficiently many users depend on the feature).
End of life
There are two ways that a function might reach the end of its life: it might be superseded or deprecated.
- A
2 function has a better alternative available, but the function itself is not going away. While a superseded function will not receive new features, it will be kept working for the foreseeable future so that existing code does not need to change. A superseded feature preserves all the guarantees of a stable feature, and is just as safe to use. - A
function has a better alternative available and will be removed in the near future. Deprecated functions should also produce a message describing the alternative, and whenever you encounter a deprecation message in your code, you should make fixing it a priority.
Particularly important functions can have two additional stages in the deprecation cycle:
Soft-deprecated comes before deprecated. It’s a gentler form of deprecated designed to prevent new uses of a function and encourage package developers to move to a new for. Soft deprecated allows a package to change its extension interface in a way that downstream dependencies can adapt to before users are forced to change.
Defunct comes after deprecated. A defunct function is still exported, and a defunct argument is still part of the signature, but their usage will generate informative errors.
Sometimes the author of function is no longer certain that a function is the optimal approach, but doesn’t yet know how to do it better. These functions can be marked as 
to give users a heads up that the author has doubts about the function.
Documentation
Experimental, questioning, superseded, and deprecated (including soft-deprecated and defunct functions) should be clearly labelled in the document with a badge:
Call
usethis::use_lifecycle()to import the badges in your package. Then uselifecycle::badge()to insert a badge:This badge renders as text in non-HTML documentation. To document the status of a whole function, a good place to include the badge is at the top of the
@descriptionblock. To document an argument, you can put the badge in the argument description.lifecycle::badge()is only ran by roxygen, so this is a build-time dependency. You don’t need to import lifecycle just to include badges in your documentation.You should also include a brief description of why the function is in that state.
For superseded and deprecated functions, rewrite the examples showing how to translate from the old to new syntax.
For deprecated functions, add
@keywords internaland update_pkgdown.yaml(if you use pkgdown), so that they’re no longer listed in documentation indexes.
Signals
Deprecated functions should clearly signal their deprecation status. There are three levels of verbosity:
Soft deprecation: Call
deprecate_soft()to start warning users about the deprecation in the least disruptive way. This function only warns (a) users who try the feature from the global workspace (at most once every 8 hours), and (b) developers who directly use the feature (when running testthat tests). No warning is when the deprecated feature is called indirectly by another package.Deprecation: Call
deprecate_warn()to warn unconditionally about the deprecated feature. The warning is issued only once every 8 hours.Defunct: Call
deprecate_stop()to fail with an error.
The following sections describe the details when deprecating functions and arguments.
Functions
The first two arguments give the version where deprecation occurred3 and a description of what is deprecated:
deprecate_warn("1.0.0", "mypkg::foo()")
#> Warning: `foo()` is deprecated as of mypkg 1.0.0.
#> This warning is displayed once every 8 hours.
#> Call `lifecycle::last_warnings()` to see where this warning was generated.Where possible, describe the replacement in the third argument:
deprecate_warn("1.0.0", "mypkg::foo()", "new()")
#> Warning: `foo()` is deprecated as of mypkg 1.0.0.
#> Please use `new()` instead.
#> This warning is displayed once every 8 hours.
#> Call `lifecycle::last_warnings()` to see where this warning was generated.We explicitly mention the namespace in these examples, but you can typically omit the namespace because lifecycle will infer it from the calling environment. Specifying the namespace is mostly useful when the replacement is implemented in a different package.
Arguments
The syntax for deprecating arguments is similar:
deprecate_warn("1.0.0", "mypkg::foo(arg = )")
#> Warning: The `arg` argument of `foo()` is deprecated as of mypkg 1.0.0.
#> This warning is displayed once every 8 hours.
#> Call `lifecycle::last_warnings()` to see where this warning was generated.
deprecate_warn("1.0.0", "mypkg::foo(arg = )", "mypkg::foo(new = )")
#> Warning: The `arg` argument of `foo()` is deprecated as of mypkg 1.0.0.
#> Please use the `new` argument instead.
#> This warning is displayed once every 8 hours.
#> Call `lifecycle::last_warnings()` to see where this warning was generated.An argument can be partially deprecated by disallowing certain input types:
deprecate_warn("1.0.0", "mypkg::foo(arg = 'must be a scalar integer')")
#> Warning: The `arg` argument of `foo()` must be a scalar integer as of mypkg 1.0.0.
#> This warning is displayed once every 8 hours.
#> Call `lifecycle::last_warnings()` to see where this warning was generated.lifecycle also provides the deprecated() sentinel to use as default argument. This provides self-documentation for your users and makes it possible for external tools to determine which arguments are deprecated. Test whether the argument was supplied by the caller with lifecycle::is_present():
foobar_adder <- function(foo, bar, baz = deprecated()) {
# Check if user has supplied `baz` instead of `bar`
if (lifecycle::is_present(baz)) {
# Signal the deprecation to the user
deprecate_warn("1.0.0", "foobar_adder(baz = )", "foobar_adder(bar = )")
# Deal with the deprecated argument for compatibility
bar <- baz
}
foo + bar
}Workflow
Where do these deprecation warnings come from?
Call lifecycle::last_warnings() to see backtraces for all the deprecation warnings that were issued during the last top-level command.
Bumping deprecation stage
Some manual search and replace is needed to bump the status of deprecated features. We recommend starting with defunct features and work your way up:
Search for
deprecate_stop()and remove the feature from the package. The feature is now archived.Search for
deprecate_warn()and replace withdeprecate_stop().Search for
deprecate_soft()and replace withdeprecate_warn().Call
deprecate_soft()from newly deprecated functions.
Don’t forget to update the badges in the documentation topics.
Find out what deprecated features you rely on
Test whether your package depends on deprecated features directly or indirectly by setting the verbosity option in the tests/testthat.R file just before test_check() is called:
This forces all deprecated features to fail. You can also set the relevant options manually to force warnings or errors in your session:
# Force silence
options(lifecycle_verbosity = "quiet")
# Force warnings
options(lifecycle_verbosity = "warning")
# Force errors
options(lifecycle_verbosity = "error")Forcing warnings can be useful in conjuction with last_warnings(), which prints backtraces for all the deprecation warnings issued during the last top-level command.
Test deprecated features
Test whether a deprecated feature still works by setting lifecycle_verbosity to "quiet":
test_that("`baz` argument of `foobar_adder()` still works", {
withr::local_options(list(lifecycle_verbosity = "quiet"))
foobar_adder(1, baz = 2)
})You can also set up verbosity for a whole testthat file within setup() and teardown() blocks:
Test that a feature is correctly deprecated with expect_deprecated() or expect_defunct():
test_that("`baz` argument of `foobar_adder()` is deprecated", {
expect_deprecated(foobar_adder(1, baz = 2))
})
test_that("`foo()` is defunct", {
expect_defunct(foo())
})More control over verbosity can be exercised with the lifecycle_verbosity option. See ?verbosity.
Communicate lifecycle changes in your functions
lifecycle provides a standard way to document the lifecycle stages of functions and arguments, paired with tools to steer users away from deprecated functions. Before we go in to the details, make sure that you’re familiar with the lifecycle stages as described in vignette("stages").
Basics
lifecycle badges make it easy for users to see the lifecycle stage when reading the documentation. To use the badges, first call usethis::use_lifecycle() to embed the badge images in your package (you only need to do this once), then use lifecycle::badge() to insert a badge:
#' `r lifecycle::badge("experimental")`
#' `r lifecycle::badge("deprecated")`
#' `r lifecycle::badge("superseded")`Deprecated functions also need to advertise their status when run. lifecycle provides deprecate_warn() which takes three main arguments:
The first argument,
when, gives the version number when the deprecation occurred.The second argument,
what, describes exactly what was deprecated.The third argument,
with, provides the recommended alternative.
We’ll cover the details shortly, but here are a few sample uses:
lifecycle::deprecate_warn("1.0.0", "old_fun()", "new_fun()")
#> Warning: `old_fun()` was deprecated in lifecycle 1.0.0.
#> Please use `new_fun()` instead.
lifecycle::deprecate_warn("1.0.0", "fun()", "testthat::fun()")
#> Warning: `fun()` was deprecated in lifecycle 1.0.0.
#> Please use `testthat::fun()` instead.
lifecycle::deprecate_warn("1.0.0", "fun(old_arg)", "fun(new_arg)")
#> Warning: The `old_arg` argument of `fun()` is deprecated as of lifecycle 1.0.0.
#> Please use the `new_arg` argument instead.(Note that the message includes the package name — this is automatically discovered from the environment of the calling function so will not work unless the function is called from the package namespace.)
The following sections describe how to use lifecycle badges and functions together to handle a variety of common development tasks.
Functions
Deprecate a function
First, add a badge to the the @description block1. Briefly describe why the deprecation occurred and what to use instead.
#' Add two numbers
#'
#' @description
#' `r lifecycle::badge("deprecated")`
#'
#' This function was deprecated because we realised that it's
#' a special case of the [sum()] function.Next, update the examples to show how to convert from the old usage to the new usage:
#' @examples
#' add_two(1, 2)
#' # ->
#' sum(1, 2)Then add @keywords internal to remove the function from the documentation index. If you use pkgdown, also check that it’s no longer listed in _pkgdown.yml. These changes reduce the chance of new users coming across a deprecated function, but don’t prevent those who already know about it from referring to the docs.
#' @keywords internalYou’re now done with the docs, and it’s time to add a warning when the user calls your function. Do this by adding call to deprecate_warn() on the first line of the function:
add_two <- function(x, y) {
lifecycle::deprecate_warn("1.0.0", "add_two()", "base::sum()")
x + y
}
add_two(1, 2)
#> Warning: `add_two()` was deprecated in lifecycle 1.0.0.
#> Please use `base::sum()` instead.
#> [1] 3deprecate_warn() generates user friendly messages for two common deprecation alternatives:
Function in same package:
lifecycle::deprecate_warn("1.0.0", "fun_old()", "fun_new()")Function in another package:
lifecycle::deprecate_warn("1.0.0", "old()", "package::new()")
For other cases, use the details argument to provide your own message to the user:
add_two <- function(x, y) {
lifecycle::deprecate_warn(
"1.0.0",
"add_two()",
details = "This function is a special case of sum(); use it instead."
)
x + y
}
add_two(1, 2)
#> Warning: `add_two()` was deprecated in lifecycle 1.0.0.
#> This function is a special case of sum(); use it instead.
#> [1] 3It’s good practice to test that you’ve correctly implemented the deprecation, testing that the deprecated function still works and that it generates a useful warning. Using an expectation inside testthat::expect_snapshot()2 is a convenient way to do this:
test_that("add_two is deprecated", {
expect_snapshot({
x <- add_two(1, 1)
expect_equal(x, 2)
})
})If you have existing tests for the deprecated function you can suppress the warning in those tests with the lifecycle_verbosity option:
test_that("add_two returns the sum of its inputs", {
withr::local_options(lifecycle_verbosity = "quiet")
expect_equal(add_two(1, 1), 2)
})And then add a separate test specifically for the deprecation.
test_that("add_two is deprecated", {
expect_snapshot(add_two(1, 1))
})Gradual deprecation
For particularly important functions, you can choose to add two other stages to the deprecation process:
deprecate_soft()is used beforedeprecate_warn(). This function only warns (a) users who try the feature from the global environment and (b) developers who directly use the feature (when running testthat tests). There is no warning when the deprecated feature is called indirectly by another package — the goal is to ensure that warn only the person who has the power to stop using the deprecated feature.deprecate_stop()comes afterdeprecate_warn()and generates an error instead of a warning. The main benefit over simply removing the function is that the user is informed about the replacement.
If you use these stages you’ll also need a process for bumping the deprecation stage for major and minor releases. We recommend something like this:
Search for
deprecate_stop()and consider if you’re ready to the remove the function completely.Search for
deprecate_warn()and replace withdeprecate_stop(). Remove the remaining body of the function and any tests.Search for
deprecate_soft()and replace withdeprecate_warn().
Rename a function
To rename a function without breaking existing code, move the implementation to the new function, then call the new function from the old function, along with a deprecation message:
#' Add two numbers
#'
#' @description
#' `r lifecycle::badge("deprecated")`
#'
#' `add_two()` was renamed to `number_add()` to create a more
#' consistent API.
#' @keywords internal
#' @export
add_two <- function(foo, bar) {
lifecycle::deprecate_warn("1.0.0", "add_two()", "number_add()")
number_add(foo, bar)
}
# documentation goes here...
#' @export
number_add <- function(x, y) {
x + y
}If you are renaming many functions as part of an API overhaul, it’ll often make sense to document all the changes in one file, like https://rvest.tidyverse.org/reference/rename.html.
Supersede a function
Superseding a function is simpler than deprecating it, since you don’t need to steer users away from it with a warning. So all you need to do is add a superseded badge:
#' Gather columns into key-value pairs
#'
#' @description
#' `r lifecycle::badge("superseded")`Then describe why the function was superseded, and what the recommended alternative is:
#'
#' Development on `gather()` is complete, and for new code we recommend
#' switching to `pivot_longer()`, which is easier to use, more featureful,
#' and still under active development.
#'
#' In brief,
#' `df %>% gather("key", "value", x, y, z)` is equivalent to
#' `df %>% pivot_longer(c(x, y, z), names_to = "key", values_to = "value")`.
#' See more details in `vignette("pivot")`.The rest of the documentation can stay the same.
If you’re willing to live on the bleeding edge of lifecycle, add a call to the experimental signal_stage():
gather <- function(data, key = "key", value = "value", ...) {
lifecycle::signal_stage("superseded", "gather()")
}This signal isn’t currently hooked up to any behaviour, but we plan to provide logging and analysis tools in a future release.
Mark function as experimental
To advertise that a function is experimental and the interface might change in the future, first add an experimental badge to the description:
#' @description
#' `r lifecycle::badge("experimental")`If the function is very experimental, you might want to add @keywords internal too.
If you’re willing to try an experimental lifecycle feature, add a call to signal_stage() in the body:
cool_function <- function() {
lifecycle::signal_stage("experimental", "cool_function()")
}This signal isn’t currently hooked up to any behaviour, but we plan to provide logging and analysis tools in a future release.
Arguments
Deprecate an argument, keeping the existing default
Take this example where we want to deprecate na.rm in favour of always making it TRUE.
add_two <- function(x, y, na.rm = TRUE) {
sum(x, y, na.rm = na.rm)
}First, add a badge to the argument description:
#' @param na.rm `r lifecycle::badge("deprecated")` `na.rm = FALSE` is no
#' longer supported; this function will always remove missing valuesAnd add a deprecation warning if na.rm is FALSE. In this case, there’s no replacement to the behaviour, so we instead use details to provide a custom message:
add_two <- function(x, y, na.rm = TRUE) {
if (!isTRUE(na.rm)) {
lifecycle::deprecate_warn(
when = "1.0.0",
what = "add_two(na.rm)",
details = "Ability to retain missing values will be dropped in next release."
)
}
sum(x, y, na.rm = na.rm)
}
add_two(1, NA, na.rm = TRUE)
#> [1] 1
add_two(1, NA, na.rm = FALSE)
#> Warning: The `na.rm` argument of `add_two()` is deprecated as of lifecycle 1.0.0.
#> Ability to retain missing values will be dropped in next release.
#> [1] NADeprecating an argument, providing a new default
Alternatively, you can change the default value to lifecycle::deprecated() to make the deprecation status more obvious from the outside, and use lifecycle::is_present() to test whether or not the argument was provided. Unlike missing(), this works for both direct and indirect calls.
#' @importFrom lifecycle deprecated
add_two <- function(x, y, na.rm = deprecated()) {
if (lifecycle::is_present(na.rm)) {
lifecycle::deprecate_warn(
when = "1.0.0",
what = "add_two(na.rm)",
details = "Ability to retain missing values will be dropped in next release."
)
}
sum(x, y, na.rm = na.rm)
}The chief advantage of this technique is that users will get a warning regardless of what value of na.rm they use:
add_two(1, NA, na.rm = TRUE)
#> Warning: The `na.rm` argument of `add_two()` is deprecated as of lifecycle 1.0.0.
#> Ability to retain missing values will be dropped in next release.
#> [1] 1
add_two(1, NA, na.rm = FALSE)
#> Warning: The `na.rm` argument of `add_two()` is deprecated as of lifecycle 1.0.0.
#> Ability to retain missing values will be dropped in next release.
#> [1] NARenaming an argument
You may want to rename an argument if you realise you have made a mistake with the name of an argument. For example, you’ve realised that an argument accidentally uses . to separate a compound name, instead of _. You’ll need to temporarily permit both arguments, generating a deprecation warning when the user supplies the old argument:
add_two <- function(x, y, na_rm = TRUE, na.rm = deprecated()) {
if (lifecycle::is_present(na.rm)) {
lifecycle::deprecate_warn("1.0.0", "add_two(na.rm)", "add_two(na_rm)")
na_rm <- na.rm
}
add_two(x, y, na.rm = na_rm)
}Reducing allowed inputs to an argument
To narrow the set of allowed inputs, call deprecate_warn() only when the user supplies the previously supported inputs. Make sure you preserve the previous behaviour:
add_two <- function(x, y) {
if (length(y) != 1) {
lifecycle::deprecate_warn("1.0.0", "foo(y = 'must be a scalar')")
y <- sum(y)
}
x + y
}
add_two(1, 2)
#> [1] 3
add_two(1, 1:5)
#> Warning: The `y` argument of `foo()` must be a scalar as of lifecycle 1.0.0.
#> [1] 16Lifecycle stages
This vignette describes the four primary stages of the tidyverse lifecycle: stable, deprecated, superseded, and experimental.
A diagram showing the transitions between the four main stages: experimental can become stable and stable can become deprecated or superseded.
The lifecycle stages can apply to packages, functions, function arguments, and even specific values of a function argument. However, you’ll mostly see them used to label individual functions, so that’s the language we use below.
Stable
The default development stage is . A function is considered stable when the author is happy with its interface, doesn’t see major issues, and is happy to share it with the world. Because this stage is the default, functions will only be given a stable badge if there’s some specific need to draw attention to their status.
Stability is defined in terms of breaking changes. A breaking change is a change that breaks code that uses the function as expected. In general, breaking changes reduce the set of code that works without error, either by removing a function, removing a function argument, or decreasing the set of valid inputs. Breaking changes also include changes to output type. If you imagine all the possible inputs to a function that return a result (and not an error), a breaking change makes the set smaller.
Not all changes that cause your function to stop working are breaking changes. For example, you might have accidentally relied on a bug. When the bug is fixed, your code breaks, but this is not a breaking change. A good way of making your code more robust to this sort of behaviour change is to only use a function for its explicitly intended effects. For example, using c() to concatenate two vectors will not put your code at risk because it clearly is the intended usage of this function. On the other hand, using c() just for the side effect of removing attributes is probably not a good idea. If you use c(factor("foo")) to retrieve the underlying integers of the factor levels, your code is at risk of breaking if c() ever implements a factor method.
Stable functions come with two promises related to breaking changes:
Breaking changes will be avoided where possible. We’ll only make breaking changes if we consider the long term benefit of the change to be greater than short term pain of changing existing code.
If a breaking change is needed, it will occur gradually, through the deprecation process described next. This gives you plenty of time to adjust your code before it starts generating errors.
Deprecated
A function has a better alternative available and is scheduled for removal. When you call a deprecated function, you get a warning telling you what to use instead. For example, take tibble::as_data_frame():
df <- tibble::data_frame(x = 1)
#> Warning message:
#> `data_frame()` is deprecated as of tibble 1.1.0.
#> Please use `tibble()` instead.
#> This warning is displayed once every 8 hours.
#> Call `lifecycle::last_lifecycle_warnings()` to see where this warning was generated. The deprecation warning tells you when the function was deprecated (in tibble 1.1.0, released in 2016), and what to use instead (tibble()). To avoid being too annoying, deprecation messages will only appear once per session, and you can find out exactly where they come from by calling lifecycle::last_lifecycle_warnings(). vignette("manage") provides more advice on handling deprecation warnings in your code.
Particularly important functions may go through two additional stages of deprecation:
Soft deprecated comes before deprecated. It’s a gentler form of deprecation designed to prevent new uses of a function and encourage package developers to move away from it. Soft deprecated allows a package to change its interface to encourage package developers to update their code before their users are forced to change.
Defunct comes after deprecated. In most cases, a deprecated function will eventually just be deleted. For very important functions, we’ll instead make the function defunct, which means that function continues to exist but the deprecation warning turns into an error. This is more user-friendly than just removing the function because users will get a clear error message explaining why their code no longer works and how they can fix it.
Superseded
A softer alternative to deprecation is superseded. A 1 function has a known better alternative, but the function itself is not going away . A superseded function will not emit a warning (since there’s no risk if you keep using it), but the documentation will tell you what we recommend instead .
Superseded functions will not receive new features, but will receive any critical bug fixes needed to keep it working. In some ways a superseded function is actually safer than a stable function because it’s guaranteed never to change (for better or for worse).
Experimental
Some functions are released in an stage. Experimental functions are made available so people can try them out and provide feedback, but come with no promises for long term stability. In particular, the author reserves the right to make breaking changes without a deprecation cycle. That said, there is some interaction between popularity and stability. Breaking an popular function, even if clearly labelled as experimental, is likely to cause widespread pain so we’ll generally try to avoid it.
In general, you can assume any package with version number less than 1.0.0 is at least somewhat experimental, and it may have major changes in its future. The most experimental packages only exist on GitHub. If you’re using a non-CRAN package you should plan for an active relationship: when the package changes, you need to be prepared to update your code.
Superseded stages
We no longer use these stages, but we document them here because we have used them in the past.
Questioning
Sometimes the author of a function is no longer certain that a function is the optimal approach, but doesn’t yet know how to do it better. These functions can be marked as to give users a heads up that the author has doubts about the function. Because knowing that a function is questioning is not very actionable, we no longer use or recommend this stage.
Maturing
Previously we used as 
for functions that lay somewhere between experimental and stable. We stopped using this stage because, like questioning, it’s not clear what actionable information this stage delivers.
This stage was previously called retired.↩︎
Manage lifecycle changes in functions you use
The lifecycle package uses warnings to tell you about deprecated functions. Deprecated functions will be removed in a future release, so it’s good practice to eliminate the warnings as soon as you see them.
For example, lets imagine your code uses tibble::data_frame(), which was deprecated in favour of tibble() in version 1.1.0. data_frame() now looks something like this:
data_frame <- function(...) {
lifecycle::deprecate_warn("1.1.0", "data_frame()", "tibble()")
tibble::tibble(...)
}That means if you use data_frame() in your own code you’ll get a warning:
df1 <- data_frame(x = 1, y = 2)
#> Warning: `data_frame()` was deprecated in tibble 1.1.0.
#> Please use `tibble()` instead.
#> This warning is displayed once every 8 hours.
#> Call `lifecycle::last_lifecycle_warnings()` to see where this warning was generated.
df2 <- data_frame(a = "apple", b = "banana")
#> Warning: `data_frame()` was deprecated in tibble 1.1.0.
#> Please use `tibble()` instead.You’ll notice that the warning only appears the first time we call it — lifecycle only notifies you every 8 hours so it’s not overly disruptive if you’ve used a deprecated function in many places.
So how do you track down exactly where the warning came from? Firstly, you might notice the deprecation warning message includes the advice to call lifecycle::last_lifecycle_warnings(). That’ll give you a list of all the deprecation warnings that have happened recently:
lifecycle::last_lifecycle_warnings()
#> [[1]]
#> <deprecated>
#> message: `data_frame()` was deprecated in tibble 1.1.0.
#> Please use `tibble()` instead.
#> Backtrace:
#> 1. global::data_frame(x = 1)Each warning comes with a back trace that shows you the full sequence of calls that lead to the deprecated function.
Alternatively, if you’re ready to spend some time tracking down all your uses of deprecated functions, you can use the lifecycle_verbosity option to make deprecated functions warn every time:
options(lifecycle_verbosity = "warning")
df1 <- data_frame(x = 1, y = 2)
#> Warning: `data_frame()` was deprecated in tibble 1.1.0.
#> Please use `tibble()` instead.
df2 <- data_frame(a = "apple", b = "banana")
#> Warning: `data_frame()` was deprecated in tibble 1.1.0.
#> Please use `tibble()` instead.Then use lifecycle::last_lifecycle_warnings() to track down the source.
Alternatively, if you want to be really strict, you can turn all deprecation warnings into errors, forcing you to deal with them immediately:
options("lifecycle_verbosity" = "error")
df1 <- data_frame(x = 1, y = 2)
#> Error: `data_frame()` was deprecated in tibble 1.1.0.
#> Please use `tibble()` instead.