feat: Add axiom logger, nextjs and react libraries

[gabrielelpidio]

No description provided.

[dasfmi]

I would rename the core package to match the name in package.json, so that it won't lead to confusion.

[gabrielelpidio]

I would rename the core package to match the name in package.json, so that it won't lead to confusion.

Changed this, now the code is under logger folder

[pkg-pr-new]

Open in Stackblitz

@axiomhq/js

npm i https://pkg.pr.new/axiomhq/axiom-js/@axiomhq/js@257

@axiomhq/logging

npm i https://pkg.pr.new/axiomhq/axiom-js/@axiomhq/logging@257

@axiomhq/pino

npm i https://pkg.pr.new/axiomhq/axiom-js/@axiomhq/pino@257

@axiomhq/react

npm i https://pkg.pr.new/axiomhq/axiom-js/@axiomhq/react@257

@axiomhq/nextjs

npm i https://pkg.pr.new/axiomhq/axiom-js/@axiomhq/nextjs@257

@axiomhq/winston

npm i https://pkg.pr.new/axiomhq/axiom-js/@axiomhq/winston@257

commit: e35921a

[dasfmi]

would it be easier if we simplify this import to:

import { Logger, AxiomProxyTransport, ConsoleTransport } from '@axiomhq/logging';

[bdsqqq]

Don't think so, having the transports in a separate/grouped export feels like a good separation. Reminds me of how vercel does the AI sdk, you import core functionality from the "ai" package, but need to import your models from a separate package.

ex:

import { generateText } from "ai"
import { mistral } from "@ai-sdk/mistral"

const { text } = await generateText({
  model: mistral("mistral-large-latest"),
  prompt: "What is love?"
})

it has the benefit of allowing users to have a slimmer list of options in their autocomplete when importing from the main package, mainly functionalities, and have a clear place to get these things that serve a very specific purpose that you need to pass in conjunction with other functions (transports/models)

[dasfmi]

@bdsqqq I agree to the concept, and that's what we are trying to do with the package, but the transports plays a core value (main funcationality) for the logging package and there is like 2 or 3 of them maximum. The Ai ones makes sense because they are different providers that would be implemented/developed separately as apposite to the transports here. wdyt?

[dasfmi]

I think the version here needs to be "workspace:*"

[dasfmi]

@gabrielelpidio this is still mentioning a fixed version instead of workspace version.

[dasfmi]

Make sure to go over all the package.json files in the PR and bring them closer to whats in axiom-js package.json in terms of license, contributors, homepage, repo, etc.

[gabrielelpidio]

It should be good now; check it out @dasfmi

[dasfmi]

@gabrielelpidio great work, I left some comments but they are small ones, in general looks one step closer to 100%.

[dasfmi]

One more question, how do we handle the notFound and redirect errors for Next.js? We will need to address the request for setting defaults somehow.

[gabrielelpidio]

One more question, how do we handle the notFound and redirect errors for Next.js? We will need to address the request for setting defaults somehow.

This was top of mind when doing the API for route handlers. Everything is customizable, from error handling to the ingested flow; in this case, we provide a default logErrorByStatusCode function that decides which type of log level will be sent to Axiom, depending on the status code.

axiom-js/examples/nextjs/src/app/api/route.ts

Line 29 in 86b3f3e

logger[logErrorByStatusCode(report.statusCode)](message, report);

Internally, the function does the following:

axiom-js/packages/nextjs/src/routeHandler.ts

Lines 84 to 96 in 86b3f3e

	export const logErrorByStatusCode = (statusCode: number) => {
	switch (statusCode) {
	case 404:
	case 403:
	case 401:
	return 'warn';
	case 307:
	case 308:
	return 'info';
	default:
	return 'error';
	}
	};

This means developers can create their own function, with different LogLevels depending on their needs.

Deeper look (relevant to the question, but not necessary to change the LogLevel):

On the other side, capturing the status code is done internally by the getNextErrorStatusCode function, with helpers that Next.js provides to detect if it's a redirect error or a httpFallbackError

axiom-js/packages/nextjs/src/routeHandler.ts

Lines 72 to 82 in 86b3f3e

	export const getNextErrorStatusCode = (error: Error & { digest?: string }) => {
	if (!error.digest) {
	return 500;
	}
	if (isRedirectError(error)) {
	return error.digest.split(';')[3];
	} else if (isHTTPAccessFallbackError(error)) {
	return error.digest.split(';')[1];
	}
	};

All this also means that the function that handles errors and the default callback are just coupling these pieces together, and if the developer wants they can use as many helpers as they want from what we export

axiom-js/packages/nextjs/src/routeHandler.ts

Lines 33 to 48 in 86b3f3e

	export const transformErrorResult = (data: ErrorData): [message: string, report: Record<string, any>] => {
	const statusCode = data.error instanceof Error ? getNextErrorStatusCode(data.error) : 500;
	const report = {
	type: 'request',
	method: data.req.method,
	url: data.req.url,
	statusCode: statusCode,
	durationMs: data.end - data.start,
	path: new URL(data.req.url).pathname,
	endTime: data.end,
	startTime: data.start,
	};
	return [`${data.req.method} ${report.path} ${report.statusCode} in ${report.endTime - report.startTime}ms`, report];
	};

axiom-js/packages/nextjs/src/routeHandler.ts

Lines 98 to 110 in 86b3f3e

	export const createDefaultAxiomHandlerCallback = (logger: Logger): axiomHandlerCallback => {
	return async (result) => {
	if (result.ok) {
	logger.info(...transformSuccessResult(result.data));
	} else {
	if (result.data.error instanceof Error) {
	logger.error(result.data.error.message, result.data.error);
	const [message, report] = transformErrorResult(result.data);
	logger[logErrorByStatusCode(report.statusCode)](message, report);
	}
	}
	};
	};

All of this lives in a single file under /packages/nextjs/src/routeHandler.ts

[gabrielelpidio]

Make sure log level works if it's gonna be included

[dasfmi]

@gabrielelpidio this is still mentioning a fixed version instead of workspace version.

[dasfmi]

nitpick: insert a new line before interface.

[dasfmi]

I don't like how the index file is import/export other transports, and the other transports are importing the Transport interface, cycle dependencies are always weird. I would prefer if the Transport interface lived in its own file in the src folder.

[dasfmi]

Perhaps you can be more flexible with the versioning here, something like >=15.1

[dasfmi]

Wondering if this should this be a peer dependency or not? No strong opinion though