Publish Protocol-Common as an ESM library

[ghost]

Resolves #52 Resolves #69

Summary of Changes:

• Build artifact now uses ESM instead of CommonJS
  • Part of this change requires that all imports in the library specify the .js extension when importing local components.
• BREAKING CHANGE: Build artifact includes a top-level index.js where all the components of the library have been re-exported. Dependents of this library need to update their imports to be shallow imports rather than deep imports.
  • E.g. import { Logger } from 'protocol-common/logger'; should now be import { Logger } from 'protocol-common';
  • Exception: one separate index.js for the validation sub-library
• BREAKING CHANGE: Build artifact now bundles all type declarations into a single top-level index.d.ts
  • Exception: one separate index.d.ts for the validation sub-library
• BREAKING CHANGE: Deprecated the old Logger + DatadogLogger classes based on Winston for new ProtocolLogger + ProtocolLoggerModule classes based on Pino. The new way to use this is to import the ProtocolLoggerModule in your AppModule and then have the app.useLogger() function use NestJS dependency injection to retrieve the ProtocolLogger.
  • This is one of the things that needs to be documented in a follow-up PR once this PR has been confirmed to work in our other repos.
• Add ProtocolHttpModule so that dependents of protocol-common no longer need to import the proper @nest/axios version or update their dependencies every time protocol-common updates. This is not technically a breaking change because the old way of working with the library will still work, it's just deprecated.
  • Also, this updates @nest/axios to the latest version.
• Update version to 1.1.0
• Fix some lint errors and grammar issues in comments

Has been tested locally using npm link against protocol-aries and aries-key-guardian. This version should still be considered experimental as it has not yet been fully tested against components that have protocol-aries as a dependency.

Still TODO is to update documentation on how to use this. This has been held off on until these changes can be considered as no longer experimental.

[ghost]

I wish there was a way to get rid of the .js on import statements.

I'm totally with you on this. There is a way to get rid of it, but it involves an experimental flag which may not be supported in the future, so the most forward-looking approach is just to include the .js.