ESLintify the library and its examples, enable linting in CI

[matux]

Most changes come from the updated package-lock.json in the nextjs example project.

Description of the change

This is the ESLint portion of the prettier/eslint + ci effort. All warnings and errors have been addressed.

Explanatory comments in file changes.

Type of change

• Bug fix (non-breaking change that fixes an issue)
• New feature (non-breaking change that adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Maintenance
• New release

Checklists

Development

• Lint rules pass locally
• The code changed/added as part of this pull request has been covered with tests
• All tests related to the changed code pass in development

Code review

• This pull request has a descriptive title and information useful to a reviewer. There may be a screenshot or screencast attached
• "Ready for review" label attached to the PR and reviewers assigned
• Issue from task tracker has a link to this pull request
• Changes have been reviewed by at least one other engineer

[matux]

This file isn't part of a project but a repertoire of snippets exploring how Rollbar may be used.

So, these checks are bothersome, and the snippets are more explanatory if they look "as if" they were part of an actual larger project.

[matux]

I may end up adding this as a file comment, actually.

[matux]

When omitting the type parameter, it defaults to any already.

[matux]

This one was a fun type-structure puzzle.

So, Provider expects a ProviderProps-type-like structure which is defined like so:

export interface ProviderProps {
  Rollbar?: new (options: Configuration) => Rollbar
  children: ReactNode
  config?: Configuration | (() => Configuration)
  instance?: Rollbar
}

The solution is two-fold.

First

We need to acknowledge that we're providing the expected type structure through two arguments, props supplies the only required prop children, and providerProps supplies the rest of the props which are all optional.

Second

This is one is a bit harder to explain. The function render is loosely declared as: render(_, RenderOptions), we only care about the second argument RenderOptions which has a bunch of props and a wrapper?: React.ComponentType which is in turn, the one we care about.

ComponentType is defined as:

type ComponentType<P = {}> = ComponentClass<P> | FunctionComponent<P>;

Since we're passing a function (props) => ..., we are matching FunctionComponent's structure which has a bunch of props and the main one, the function, which is defined as:

interface FunctionComponent<P = {}> {
  (props: PropsWithChildren<P>, context?: any): ReactElement<any, any> | null;
  ...
}  

So, the props we get here: (props) => <Provider {...props} {...providerProps} />, is of type PropsWithChildren which is defined:

type PropsWithChildren<P> = P & { children?: ReactNode | undefined };

And therein lies the second problem. The children prop is optional, but ProviderProps requires it. So, we solve this by creating a new object that matches the structure in ProviderProps, and we either pass props.children if there's something in it, or an empty node.

And voila, all types check!

Fun for the whole family.

A note on P: Given there's no type parameter defined in wrapper?: React.ComponentType, we know for a fact that that P = {}, therefore props is effectively of type { children?: ReactNode }.