Closes #13921.

Background

As far as I'm aware, provide is only intended to be used during the creation of a component. The provided values are expected to be locked in once the component renders. Any descendants shouldn't need to worry about timing, any provided values will be ready immediately and won't change. This is baked into the design of provide/inject.

I believe the original intention was for provide to only work directly inside setup (both the warning message and the documentation suggest this too). But, in practice, it doesn't check for that, it only checks for the availability of currentInstance. That is available in other places, such as inside lifecycle hooks.

As pointed out in #13921, calling provide inside a lifecycle hook does mostly work, but not completely. Some parts of the code appear to have been written under the assumption that the provided values are only set prior to mounting. In my opinion, this is a valid assumption and the only change that is required is to tighten up the warnings to avoid incorrect usage.

I've extended the warning to also check for currentInstance.isMounted. This will lead to a warning in cases like this:

onMounted(() => {
 provide('foo', 'bar')
})

Why isMounted?

I chose to use currentInstance.isMounted for my check because I think it reflects the underlying restriction. You could, for example, still use provide inside onBeforeMounted. I'm not sure why that would be useful, but so long as the component hasn't mounted yet I didn't see any reason to log a warning.

Impact on existing applications

This PR only adds extra warnings, it shouldn't change how provide behaves. If someone is using provide inside onMounted then it will still 'work' as it did previously, just with an extra warning. In that sense, it's relatively safe to merge and shouldn't impact production builds.

I've marked this change as a fix because I think it needs to be included in the changelog. There will likely be some people who encounter this warning after upgrading and it would be helpful for them to be able to find this PR.

I'm not sure what the use case for calling provide inside a lifecycle hook would be. It would still need to be called during the synchronous execution of the hook, so it isn't really suited to asynchronous tasks such as loading data. Perhaps there's a use case involving providing values that come from template refs?

In any case, if provide is being used inside onMounted then I believe the 'correct' way to handle that would be to provide a ref during setup instead, then update that ref from inside onMounted.

I'm not sure whether this would impact any libraries. I did have a quick look through VueUse. From what I could tell it doesn't use provide and inject much, so it shouldn't be a problem.

Tests

The existing warning message wasn't being tested. Most of the test cases I've added are testing the existing code on main, so even if the other changes in this PR aren't viable it may still be possible to merge some of those tests. Only the final test is actually testing my change to provide.

Summary by CodeRabbit

• Bug Fixes

  • Improved development-time warnings for incorrect use of dependency injection APIs, including usage outside setup and after component mount.
  • Ensures warnings trigger reliably without affecting normal runtime behavior.

• Tests

  • Added comprehensive test coverage for warning scenarios, including misuse in render functions and lifecycle hooks.