Added link to v2 docs. Added deprecation warnings throughout v1 docs.

adzejs · Sep 9, 2024 · 720743f · 720743f
1 parent 919c52d
commit 720743f
Show file tree

Hide file tree

Showing 22 changed files with 22,776 additions and 0 deletions.
diff --git a/docs/.vuepress/config.js b/docs/.vuepress/config.js
@@ -134,6 +134,10 @@ module.exports = {
     lastUpdated: false,
     sidebarDepth: 1,
     nav: [
+      {
+        text: 'v2.x',
+        link: 'https://adzejs.com/',
+      },
       {
         text: 'Guide',
         link: '/guide/',

diff --git a/docs/addons/creating-addons.md b/docs/addons/creating-addons.md
@@ -1,5 +1,9 @@
 # Creating Add-on's
 
+:::danger
+This version is now deprecated! Please upgrade to [version 2](https://adzejs.com/)!
+:::
+
 One of the core tenets of Adze is to **not do too much**. This means that the core functionality of Adze is to provide the user with the ability to have control over their logs, how they are shaped, and to be able to listen to their logs and do with the log data as they please. Anything resembling transporting log data to files, API's, or databases is purposefully omitted from the core. However, because of Adze [log listeners](../guide/shed-concepts.md#listeners), there is opportunity for add-on packages to provide simple solutions for handling log data transports and various other solutions.
 
 ## Best Practices

diff --git a/docs/addons/official-addons.md b/docs/addons/official-addons.md
@@ -1,5 +1,9 @@
 # Official Add-on's
 
+:::danger
+This version is now deprecated! Please upgrade to [version 2](https://adzejs.com/)!
+:::
+
 The following list contains add-on's that are officially supported by core Adze contributors and are maintained under the [`@adze` npm organization namespace](). We hope that over time this list will grow and hopefully community created add-on's can be adopted by the official organization.
 
 ---

diff --git a/docs/config/README.md b/docs/config/README.md
@@ -4,6 +4,10 @@ sidebar: auto
 
 # Config
 
+:::danger
+This version is now deprecated! Please upgrade to [version 2](https://adzejs.com/)!
+:::
+
 Adze is a completely configurable library by design that comes with sensible defaults. There are two primary configurations to understand; the Adze configuration and the Shed configuration. In this section we'll take a look at each configuration and explain each property in detail.
 
 _NOTE: [Chalk](https://github.com/chalk/chalk#chalklevel) is what Adze uses under the hood for terminal coloring. Because terminals differ in their color fidelity, Chalk exposes a setting allowing you to specify your fidelity. Adze is basic with its colors so the low level of 1 is sufficient, however, you can change it to your liking with the `terminalColorFidelity` option described below. Please refer to the [Chalk](https://github.com/chalk/chalk#chalklevel) docs for information about what the fidelity levels mean._

diff --git a/docs/faqs/README.md b/docs/faqs/README.md
@@ -4,6 +4,10 @@ sidebar: auto
 
 # Frequently Asked Questions
 
+:::danger
+This version is now deprecated! Please upgrade to [version 2](https://adzejs.com/)!
+:::
+
 This section is dedicated to answering common problems that might occur while using Adze in your project.
 
 ## SvelteKit Error

diff --git a/docs/guide/README.md b/docs/guide/README.md
@@ -1,5 +1,9 @@
 # Introduction
 
+:::danger
+This version is now deprecated! Please upgrade to [version 2](https://adzejs.com/)!
+:::
+
 ## Why is this named Adze?
 
 ![A drawing of a man using an adze to shape a log](./assets/adze.png)

diff --git a/docs/guide/adze-concepts.md b/docs/guide/adze-concepts.md
@@ -1,5 +1,9 @@
 # Adze Concepts
 
+:::danger
+This version is now deprecated! Please upgrade to [version 2](https://adzejs.com/)!
+:::
+
 Adze as a library has a few core goals it attempts to meet. The first goal is to provide an API that wraps, extends, or replicates all of the functionality of the standard [Console API](https://developer.mozilla.org/en-US/docs/Web/API/console). The standard console API allows you to create logs based on severity, however other utility logs like table, assert, trace, etc. are all tied to the severity of `log`. Adze takes a different approach by turning these into [modifiers](modifiers.md) which can be terminated by whichever severity level you prefer.
 
 The second goal of the Adze project is to give you a natural log writing experience that doesn't feel too different from the standard. To make the experience of using Adze feel natural, Adze provides a chainable API that is similar to the standard `console.log()` API.

diff --git a/docs/guide/data.md b/docs/guide/data.md
@@ -1,5 +1,9 @@
 # Data
 
+:::danger
+This version is now deprecated! Please upgrade to [version 2](https://adzejs.com/)!
+:::
+
 In this section of the guide we'll take a look at some of the important data structures that exist across the Adze API.
 
 ## Collections

diff --git a/docs/guide/default-terminators.md b/docs/guide/default-terminators.md
@@ -1,5 +1,9 @@
 # Default Terminators
 
+:::danger
+This version is now deprecated! Please upgrade to [version 2](https://adzejs.com/)!
+:::
+
 After you generated an Adze log instance from a [factory function](factories.md) and have applied the desired [modifiers](modifiers.md) you must terminate the method chain. The methods used to terminate the chain are called **terminators**.
 
 When a log has been terminated it will generate a log render, check if it is allowed to print the log render, cache the log instance if a [Shed](/shed) exists, and then return a data object representing the log properties and the log render to any registered log listeners. After all of that it will return a [terminated log object](/guide/concepts.html#terminated-log-object).

diff --git a/docs/guide/factories.md b/docs/guide/factories.md
@@ -1,5 +1,9 @@
 # Factories
 
+:::danger
+This version is now deprecated! Please upgrade to [version 2](https://adzejs.com/)!
+:::
+
 As you know from the high-level concepts, Adze logs are typically generated from a factory function. Out-of-the-box you get the `adze()` function that is your normal entry point into creating logs. However, you can also use `seal()` and `bundle()` to take advantage of some other cool features that we will review below.
 
 ## adze

diff --git a/docs/guide/filtering-and-utility-functions.md b/docs/guide/filtering-and-utility-functions.md
@@ -1,5 +1,9 @@
 # Filtering & Utility Functions
 
+:::danger
+This version is now deprecated! Please upgrade to [version 2](https://adzejs.com/)!
+:::
+
 When working with Adze logs sometimes you may have a [Collection](advanced.md#collections) of logs that you would like to filter down to a specific subset. Adze provides you with some filtering functions out of the box to help with this. Adze also provides a couple utility functions that are explained below.
 
 ## filterCollection

diff --git a/docs/guide/getters-and-setters.md b/docs/guide/getters-and-setters.md
@@ -1,5 +1,9 @@
 # Getters and Setters
 
+:::danger
+This version is now deprecated! Please upgrade to [version 2](https://adzejs.com/)!
+:::
+
 Adze log instances have a few setters and getters that you can take advantage of.
 
 ## context

diff --git a/docs/guide/installation.md b/docs/guide/installation.md
@@ -1,5 +1,9 @@
 # Installing Adze
 
+:::danger
+This version is now deprecated! Please upgrade to [version 2](https://adzejs.com/)!
+:::
+
 ## Install the Package
 
 You can install Adze from NPM using the following command:

diff --git a/docs/guide/machine-readable-logs.md b/docs/guide/machine-readable-logs.md
@@ -1,5 +1,9 @@
 # Machine Readable Logs
 
+:::danger
+This version is now deprecated! Please upgrade to [version 2](https://adzejs.com/)!
+:::
+
 When working with your logs, typically in a production environment, the best practice is to generate logs as JSON objects. By generating them as JSON objects it makes them simpler to index, search, and sort at a later time. Adze supports this out of the box through the [`machineReadable` configuration property](#configuration). When this is enabled, all logs will cease printing in a user-friendly human-readable format and print to the console as JSON objects. These objects will contain all of the information that would normally be present in a human-readable log.
 
 ## Configuration

diff --git a/docs/guide/mapped-diagnostic-context.md b/docs/guide/mapped-diagnostic-context.md
@@ -1,5 +1,9 @@
 # Mapped Diagnostic Context (MDC)
 
+:::danger
+This version is now deprecated! Please upgrade to [version 2](https://adzejs.com/)!
+:::
+
 ## What is Mapped Diagnostic Context?
 
 _"The basic idea of Mapped Diagnostic Context is to provide a way to enrich log messages with pieces of information that could be not available in the scope where the logging actually occurs, but that can be useful to better track the execution of the program."_

diff --git a/docs/guide/micro-frontends.md b/docs/guide/micro-frontends.md
@@ -1,5 +1,9 @@
 # Micro-Frontends
 
+:::danger
+This version is now deprecated! Please upgrade to [version 2](https://adzejs.com/)!
+:::
+
 You may be asking yourself, "What are micro-frontends?" To be brief, micro-frontends are an extension of the micro-services architecture pattern all the way through to the frontend of an application.
 
 For a more detailed explanation, please visit these excellent resources:

diff --git a/docs/guide/modifiers.md b/docs/guide/modifiers.md
@@ -1,5 +1,9 @@
 # Modifiers
 
+:::danger
+This version is now deprecated! Please upgrade to [version 2](https://adzejs.com/)!
+:::
+
 Once you have an Adze log instance you can now start applying modifiers. Modifiers are methods that alter the log in some way and then return
 the log instance so that you may chain more modifiers or terminate the instance. Keep in mind, some modifiers have a dependency on the presence of a [label](#label) and labels rely on Shed.
 

diff --git a/docs/guide/other-terminators.md b/docs/guide/other-terminators.md
@@ -1,5 +1,9 @@
 # Other Terminators
 
+:::danger
+This version is now deprecated! Please upgrade to [version 2](https://adzejs.com/)!
+:::
+
 Aside from the [default terminator methods](default-terminators.md), Adze also exposes a few others for different utility purposes.
 
 ## clear / clr

diff --git a/docs/guide/shed-concepts.md b/docs/guide/shed-concepts.md
@@ -1,5 +1,9 @@
 # Shed Concepts
 
+:::danger
+This version is now deprecated! Please upgrade to [version 2](https://adzejs.com/)!
+:::
+
 ## What is a Shed?
 
 A **Shed** is an optional global cache and control hub for your Adze logs. The primary purposes of a Shed are to enable global configuration overrides and log listeners. To see how a Shed fits into the architecture, refer to the [Lifecycle Diagram](adze-concepts.html#lifecycle).

diff --git a/docs/guide/unit-testing.md b/docs/guide/unit-testing.md
@@ -1,5 +1,9 @@
 # Unit Testing
 
+:::danger
+This version is now deprecated! Please upgrade to [version 2](https://adzejs.com/)!
+:::
+
 When executing your unit tests you generally do not want to see the internal logging of the code you are testing; rather you only care about the inputs and outputs. To disable logs while executing your unit tests, within your unit test file you should set the global value `ADZE_ENV = 'test'`. This tells adze logs to prevent rendering for the sake of unit tests.
 
 ### Example

diff --git a/docs/guide/using-shed.md b/docs/guide/using-shed.md
@@ -1,5 +1,9 @@
 # Using Shed
 
+:::danger
+This version is now deprecated! Please upgrade to [version 2](https://adzejs.com/)!
+:::
+
 Let's take a deeper dive into each of Shed's public methods.
 
 ## addLabel