refactor: use @loopback/core instead of @loopback/context

docs/site/Extending-LoopBack-4.md

@@ -20,6 +20,19 @@ module implements an
 container called [Context](Context.md) as a service registry that supports
 [Dependency injection](Dependency-injection.md).
 
+{% include note.html content="The `@loopback/core` package re-exports all public
+APIs of `@loopback/context`. For consistency, we recommend the usage of
+`@loopback/core` for imports in LoopBack modules and applications unless they
+depend on `@loopback/context` explicitly. The two statements below are
+equivalent:
+
+```ts
+import {inject} from '@loopback/context';
+import {inject} from '@loopback/core';
+```
+
+" %}
+
 The IoC container decouples service providers and consumers. A service provider
 can be bound to the context with a key, which can be treated as an address of
 the service provider.

docs/site/Repositories.md

@@ -543,7 +543,7 @@ Injection:
     ```
 
 2.  Inject the bound instance into the repository property of your controller.
-    `inject` can be imported from `@loopback/context`.
+    `inject` can be imported from `@loopback/core`.
 
     ```ts
     export class AccountController {

docs/site/Sequence.md

@@ -356,8 +356,8 @@ default implementation of
 [invoke](https://github.com/strongloop/loopback-next/blob/6bafa0774662991199090219913c3dc77ad5b149/packages/rest/src/providers/invoke-method.provider.ts)
 action calls the handler function for the route with the request specific
 context and the arguments for the function. It is important to note that
-controller methods use `invokeMethod` from `@loopback/context` and can be used
-with global and custom interceptors. See
+controller methods use `invokeMethod` from `@loopback/core` and can be used with
+global and custom interceptors. See
 [Interceptor docs](Interceptors.md#use-invokemethod-to-apply-interceptors) for
 more details. The request flow for two route flavours is explained below.
 

docs/site/Update-generator.md

@@ -48,7 +48,6 @@ The following dependencies are incompatible with @loopback/[email protected]:
 - @types/node: ^10.14.6 (cli ^10.17.3)
 - @loopback/boot: ^1.2.7 (cli ^1.5.10)
 - @loopback/build: ^1.5.4 (cli ^2.0.15)
-- @loopback/context: ^1.15.0 (cli ^1.23.4)
 - @loopback/core: ^1.7.0 (cli ^1.10.6)
 - @loopback/openapi-v3: ^1.3.11 (cli ^1.10.0)
 - @loopback/repository: ^1.5.5 (cli ^1.15.3)
@@ -57,7 +56,6 @@ The following dependencies are incompatible with @loopback/[email protected]:
 - @loopback/service-proxy: ^1.1.10 (cli ^1.3.10)
 ? How do you want to proceed? Upgrade project dependencies
 - Dependency @loopback/boot: ^1.2.7 => ^1.5.10
-- Dependency @loopback/context: ^1.15.0 => ^1.23.4
 - Dependency @loopback/core: ^1.7.0 => ^1.10.6
 - Dependency @loopback/openapi-v3: ^1.3.11 => ^1.10.0
 - Dependency @loopback/repository: ^1.5.5 => ^1.15.3

docs/site/tutorials/core/3-context-in-action.md

@@ -25,6 +25,19 @@ In LoopBack 4, we implemented such capabilities in the `@loopback/context`
 module. The hierarchy of contexts becomes the universal knowledge base for the
 whole application to promote visibility, extensibility, and composability.
 
+{% include note.html content="The `@loopback/core` package re-exports all public
+APIs of `@loopback/context`. For consistency, we recommend the usage of
+`@loopback/core` for imports in LoopBack modules and applications unless they
+depend on `@loopback/context` explicitly. The two statements below are
+equivalent:
+
+```ts
+import {inject} from '@loopback/context';
+import {inject} from '@loopback/core';
+```
+
+" %}
+
 Let's walk through some code snippets to illustrate how artifacts are managed
 with `@loopback/context`.
 

examples/greeter-extension/README.md

@@ -51,8 +51,8 @@ context. In our case, we mark `GreetingService` as the extension point that
 needs to access a list of greeters.
 
 ```ts
-import {Getter} from '@loopback/context';
-import {extensionFilter, CoreTags} from '@loopback/core';
+import {CoreTags, Getter, extensionFilter} from '@loopback/core';
+
 /**
  * An extension point for greeters that can greet in different languages
  */
@@ -169,7 +169,7 @@ knowing much about one another.
 
 ```ts
 import {Greeter, asGreeter} from '../types';
-import {bind, config} from '@loopback/context';
+import {bind, config} from '@loopback/core';
 
 /**
  * Options for the Chinese greeter
@@ -235,8 +235,7 @@ app
 The process can be automated with a component:
 
 ```ts
-import {createBindingFromClass} from '@loopback/context';
-import {Component} from '@loopback/core';
+import {Component, createBindingFromClass} from '@loopback/core';
 import {GreetingService} from './greeting-service';
 import {GREETING_SERVICE} from './keys';
 

extensions/authentication-passport/README.md

@@ -223,8 +223,7 @@ import {
   AuthenticationStrategy,
   AuthenticationBindings,
 } from '@loopback/authentication';
-import {Provider} from '@loopback/core';
-import {inject} from '@loopback/context';
+import {Provider, inject} from '@loopback/core';
 
 export class PassportBasicAuthProvider<MyUser>
   implements Provider<AuthenticationStrategy> {

extensions/cron/README.md

@@ -62,7 +62,7 @@ It's also possible to extend `CronJob`.
 
 ```ts
 import {CronJob, cronJob, CronJobConfig} from '@loopback/cron';
-import {config, Provider, createBindingFromClass} from '@loopback/context';
+import {config, Provider, createBindingFromClass} from '@loopback/core';
 
 @cronJob()
 class MyCronJob extends CronJob {
@@ -86,7 +86,7 @@ Alternatively, we can also define a provider class:
 
 ```ts
 import {CronJob, cronJob, CronJobConfig} from '@loopback/cron';
-import {config, Provider, createBindingFromClass} from '@loopback/context';
+import {config, Provider, createBindingFromClass} from '@loopback/core';
 
 @cronJob()
 class CronJobProvider implements Provider<CronJob> {

extensions/logging/README.md

@@ -42,7 +42,7 @@ Now your application can add a controller as follows to leverage the logging
 facilities:
 
 ```ts
-import {inject} from '@loopback/context';
+import {inject} from '@loopback/core';
 import {Logger, logInvocation} from '@loopback/extension-logging';
 import {get, param} from '@loopback/rest';
 

packages/authorization/README.md

@@ -49,7 +49,6 @@ Then **decorating your controller methods with `@authorize`** to require the
 request to be authorized.
 
 ```ts
-import {inject} from '@loopback/context';
 import {authorize} from '@loopback/authorization';
 import {get} from '@loopback/rest';
 

packages/eslint-config/eslintrc.js

@@ -130,7 +130,7 @@ module.exports = {
          *
          * @example
          * ```ts
-         * import {inject} from '@loopback/context';
+         * import {inject} from '@loopback/core';
          * class MyController {
          *   constructor(@inject('foo') foo: string) {}
          * }