ngworker / lumberjack Goto Github PK

Use angular-eslint and tslint-to-eslint-config.

Is it possible to configure custom log levels (based on severity) of type LumberjackLogLevel and how to configure it to support the log-drivers with the custom levels? The documentation (and the underlying code) shows that the log levels are predefined and I'm not sure how to approach this.

Would benefit from implicit contextual parameters.

Revisit Trace log level.

In addition to our Angular modules with static methods returning ModuleWithProviders for injector configuration, we would like to add provide* and with* provider factories similar to Angular's own to improve the developer experience (DX) for standalone Angular applications. These can also be used with classic Angular applications.

Add a log driver that can be provided in tests and used for expectations or assertions about logs.

Note: Must not depend on Jasmine or any other test framework.

What is the motivation/use case for changing the behavior?

We want to at least have one release per major version of Angular. See #188

Describe the solution you'd like

Run the necessary migrations to upgrade to the latest version of Nx and Angular 16.x.

• Use parallel builds to support Angular v8
• Publish as separate NPM package, for example @ngworker/lumberjack-view-engine

• Use parallel builds to support Angular v8
• Publish as separate NPM package, for example @ngworker/lumberjack-view-engine?

Only one compiler flag needs to be turned off for v8 support. Something with closure compiler annotations. Depends on whether we can downgrade to TypeScript 3.4 in at least the app and e2e CI jobs. Manual verification of e2e-schematics.

What is the motivation/use case for changing the behavior?

Give the community a summary of the changes made to version 16 and our plans for the future.

Describe the solution you'd like

• Describe the new API added by @pBouillon
• Announce the future of the Agnostic Core
• Announce the support for the latest versions of Nx and Angular 16.X
• Announce the deprecation of NgModules

Additional context

See #188

Consider adding a simpler logging service for users who prefer calling a method such as logCritical('log message', { thisIs: 'my log payload' }) rather than passing full log objects or using declarative logger services.

What is the motivation/use case for changing the behavior?

We want to reach a bigger audience with the release of blog posts.

For that, we would like to cross-post to the DEV platform.

Describe the solution you'd like

Create a publication in DEV with our brand.

Additional context

#188

What is the motivation/use case for changing the behavior?

Notify the community of the changes coming in v17

Describe the solution you'd like

• Announce the migrations to Nx and Angular 17. x
• Describe the implementation of string literal unions for Lumberjack levels
• Announce deprecation of Enums for log levels and its removal on version 19.

Additional context

#188

Describe the bug

On the Usage page, the examples for injecting the service are both using the inject function instead of one of them using the constructor.

To Reproduce

Visit: https://ngworker.github.io/lumberjack/docs/usage#using-the-lumberjackservice

Expected behavior

The first example should mention a constructor-based example.

Replace for-of loop based on performance metrics.

Consider using RxJS to easily offload work using a scheduler.

Maybe even consider a web worker.

• Required or optional?
• Called name or eventName?
• Is it common between many log providers?

Describe the bug

lumberjack cannot be used together with angular 16

To Reproduce

1. run 'npm install'
2. console shows errors

could not resolve dependency:
peer: @angular/core@"^15.0.1" from @ngworker/[email protected]

Expected behavior

lumberjack should be installed and usable

Environment

• Lumberjack Version 15.0.1
• Angular version: 16.1.7

see the following excerpt from our 'package.json'

  "dependencies": {
    "@angular/animations": "16.1.7",
    "@angular/cdk": "16.1.6",
    "@angular/common": "16.1.7",
    "@angular/compiler": "16.1.7",
    "@angular/core": "16.1.7",
    "@angular/forms": "16.1.7",
    "@angular/platform-browser": "16.1.7",
    "@angular/platform-browser-dynamic": "16.1.7",
    "@angular/router": "16.1.7",
   
  },
  "devDependencies": {
    "@angular-builders/custom-webpack": "16.0.0",
    "@angular-devkit/build-angular": "16.0.0",
    "@angular-devkit/core": "16.1.6",
    "@angular-devkit/schematics": "16.1.6",
    "@angular-eslint/eslint-plugin": "16.0.3",
    "@angular-eslint/eslint-plugin-template": "16.0.3",
    "@angular-eslint/template-parser": "16.0.3",
    "@angular/cli": "~16.1.0",
    "@angular/compiler-cli": "16.1.7",
    "@angular/language-service": "16.1.7",

Get rid of no-floating-promises TSLint rule errors in unit and integration tests.

What is the motivation/use case for changing the behavior?

We want to remove TypeScript Enums and replace them with TypeScript string literal unions.

Describe the solution you'd like

• Add support for string literal unions along with the current Enums
• Deprecate current Enums and notify that they will be released on version 19

Describe alternatives you've considered

Replace the enums in one movement without deprecation. This might be necessary if supporting enums and string literal unions becomes too complex.

Additional context

#188

In separate CI workflow logic branches/matrix legs:

1. Set enableIvy: true in build step. Supported by ng-packagr version 11.1.0. Switch to @angular-devkit/build-angular:ng-packagr.
2. For the app, use @angular-devkit/build-angular version >=11.1.0.
3. Change tsconfig.lib.prod.json as seen in this example.

See angular/angular-cli@35d8adf.
See https://dev.to/angular/understanding-angular-ivy-library-compilation-246n.

The Problem

Most private properties of the project are using the Typescript private indicator instead of the native ES private properties (#).

ESLint private properties are better for libraries since they actually prohibit consumers from accessing the properties, even at runtime. This prevents unwanted dependencies on library internals.

Acceptance Criteria

Migrate all Typescript private properties to ESLint private properties.

Publish lint, test and mutation score reports to a service as part of the pipeline.

For example, SonarCloud OSS license and/or the Stryker dashboard.

Angular CLI >=13.0 only allows to partially Ivy compile Angular library bundles, that is these Angular CLI versions cannot build View Engine-compatible library bundles.

A few major Angular CLI versions from now (currently at Angular 13 at the time of writing), the Angular Compatibility Compiler will be removed and only the Angular Linker will remain, removing any support for View Engine-compatible Angular libraries.

We need something like the following:

• Version 2.x with support for Angular versions 9 through <last major version with NGCC>
• Version 3.x with support for Angular versions 12.2 through <last major versions without breaking changes in the partially compiled Angular Package Format (APM)>

Option A

• Features and patches are released across both versions 2.x and 3.x.

Option B

• Version 2.x is left as-is in a branch with the possibility of hotfix patches.
• Features are released to version 3.x only.

inject is more type-safe and should give no issue unless a class is created using its constructor instead of TestBed in test.

inject is better for base classes such as LumberjackLogger and ScopedLumberjackLogger to allow sub-classes to add their own dependencies to their constructor without having to pass the base class' dependencies if they so prefer.

The Problem

There is no way to visualize Lumberjack logs history or track their timelines.

Acceptance Criteria

As a developer, I want to visualize my logs in Redux DevTools using a custom driver.

Tasks

• Create custom driver to display the logs in the Redux DevTools

Additional Resources

• https://github.com/reduxjs/redux-devtools/blob/main/docs/Integrations/Remote.md

I'm submitting a...

[ ] Regression (a behavior that used to work and stopped working in a new release)
[ ] Bug report
[ ] Performance issue
[x] Feature request
[ ] Documentation issue or request
[ ] Support request
[ ] Other... Please describe:

Current behavior

The logger requires explicit parameters.

Expected behavior

Having the ability for logs to be augmented with implicit contextual information, e.g.:

interface ContextualInformationResolver {
  resolveContextualInformation(): Promise<Record<string, unknown>>;
}

@Injectable({
  providedIn: 'root'
})
class MyContextualInformationResolver implements ContextualInformationResolver {
  async resolveContextualInformation(): Promise<Record<string, unknown>> {
    return {
      // context
    };
  }
}

The contextual information would not used in the log message itself but rather as a separate context (that could still be used when formatting the log though, just like a timestamp).

Minimal reproduction of the problem with instructions

n/a

What is the motivation / use case for changing the behavior?

There is often information that would be useful to see with a log message but is not readily available where the message is logged (not to mention it could lose some of its structure if passed in the message itself).

Typical use cases would be:

• a correlation identifier
• a span/parent identifier
• (not relevant if the library is only used on the front-end) a user identifier, a tenant identifier, etc.

This can make it much easier to filter logs based on such information without having to pass it manually each time a log is created in the user code.

Some examples:

• Node implementation (using continuation local storage)
• Logback (JVM logger implementation, using thread local storage)

Moreover, most protocols/tools related to logging support passing such contextual information (e.g. Logstash, Kibana, etc.).

Environment

n/a

This feature should allow Lumberjack clients to determine which drivers are allowed to handle a specified log.

This can be achieved using the driver identifier and it is complementary to the Drivers filtering by level.

This feature should also allow to configure lazy-loaded driver using forFeature method and overriding the driverIdentifier.

Create a new CI workflow that gets triggered on tag push.

• Run all code quality tests
• Build the library (and copy README file)
• publish the npm package with (unknown tag)
• add the next tag if the release contains beta/ rc text (validate tag format) or latest tag if doesn't.
• remove the unknown tag.

1. Implement wrapper driver for LogRocket log-store

The Problem

Lumberjack doesn't have a proper documentation website.

The Goal

Create a Lumberjack documentation website like the spectacular one.

Tasks

• Create and configure Docusaurus documentation website
• Deploy to Github Pages
• Configure CI/CD
• Write proper documentation using the tools format

1. Implement wrapper driver for Rollbar log-store

The Problem

The lumberjack project is lagging behind in its Angular version. Currently, it is in version 11.

This will be necessary to start supporting partial Ivy compilation.

The Goals

Convert the Lumberjack repository to the latest version of Angular.

Tasks

• Migrate to the latest version of Angular, TypeScript, RxJS, and Zone.js
• Migrate to a compatible version of Jest
• Migrate Schematics to a compatible version
• Verify that sonar works by introducing a lint error

What is the motivation/use case for changing the behavior?

It is one of the Backlog item
https://github.com/ngworker/lumberjack/projects/1#card-48290635

Describe the solution you'd like

I can implement this feature but would like to know if we have any specific requirement or use case that needs to be taken care of? Please elaborate

Describe alternatives you've considered

Additional context

@LayZeeDK @NachoVazquez

This would catch end-to-end bugs early and showcase best practices for testing Lumberjack logging.

Try to use LumberjackConfig#format.

Maybe send initialized log to log drivers to detect failing log drivers early.

What is the motivation/use case for changing the behaviour?

I want to update the log levels at runtime to capture additional information for specific users of my application. This is useful when trying to debug an issue affecting a specific user without having to enable logging for all users or requiring the specific user to restart their application.

Describe the solution you'd like

A method to update a log driver's config at runtime - currently config is readonly.

Describe alternatives you've considered

• Wrapping the logger and implementing my own filtering of the logs based on this dynamic log-level configuration
• Creating a composite log driver, which creates and filters logs to the underlying drivers accordingly.

Additional context

Alternative to/replacement for the lumberjack-custom-driver template repository.

Migrate to an Nx workspace to implement and test the Nx generators/preset required for this.

Note: This behavior should be implemented if there is a well-represented need by users of this feature.

Implementing this feature allows using a different payload type or no payload at all in situations where a LumberjackLogger or LumberjackService was injected using a specified generic TPayload parameter.

Example of implementation

 protected createCriticalLogger<TCustomPayload extends TPayload | void = TPayload>(
    message: string
  ): LumberjackLoggerBuilder<TCustomPayload> {
    return this.createLoggerBuilder(LumberjackLevel.Critical, message);
  }

We should be removing @angular-devkit/build-ng-packagr and using @angular-devkit/build-angular:ng-packagr instead in angular.json but we would have to wait for ngworker/angular-versions-action#22 for our CI to work.

Is there a possible way to queue up the POST requests and send them to the server as batches? How can this be implemented in the current LumberjackHttpDriver

From how I see it, the current approach for this would be collecting the logs entries in a buffer and sending them upon reaching the maxBufferSize or flushing them on timeout if it doesn't reach the maxBufferSize. Is this something that is implementable with the Lumberjack Http Driver, and if not, how to approach this?

The Problem

Custom Loggers are the recommended way of creating logs with Lumberjack, however creating custom Loggers requires a bit of boilerplate.

The Goal

Create schematics generators to create the Custom Loggers boilerplate for us.

Tasks

• Generate logger extending LumberjackLogger
• Generate logger extending ScopedLumberjackLogger (--scope=<scope-property-value>)

The Problem

The Lumberjack CI workflow is failing because of some breaking changes with the ts-jest. This blocks us from verifying the validity of any PR.

The Goal

Return the CI workflow to successful status checks.

Add deprecation-crawler to latest major and minor versions of Angular.

The Problem

Currently, the release of the new Lumberjack version is a manual and tedious task.

The Goal

Automate the release of new versions using GH Actions.

Build the lumberjack-schematic-app project after each end-to-end schematic test.

What is the motivation/use case for changing the behavior?

Standalone provider functions have become the standard and recommended way to write Angular applications.

Lumberjack supports both APIs which increases the bundle size.

Describe the solution you'd like

Mark the Lumberjack NgModules as deprecated and notify that they will be removed in version 18.

Additional context

See #188