feat(gteam-internal): add gteam-internal subpath export, migrate tests to Vitest

[yaroslav-tykhovetskyi-apify]

Why?

A private internal package's safePushData wrapper is being merged into this repo as a subpath export, so it can be maintained alongside the existing top-level safePushData instead of as a separate package. Its test suite needs to mock the Apify SDK, which node:test can't do cleanly, so this was also a chance to stop running two different test frameworks side by side.

What?

Adds a new ./gteam-internal export backed by src/gteam-internal/. Unlike the top-level safePushData, this one calls Actor.pushData/Dataset.pushData directly instead of taking a pushFn, so scripts/check-pushdata.mjs now excludes that subfolder from its guard. apify, apify-client, and @crawlee/core are added as optional peer dependencies, needed only by consumers of this new subpath.

The whole test suite (top-level and new) now runs on Vitest. The old node:test suite was ported over with an equivalent assertion for assertion, and the test/ci npm scripts were simplified down to a single npm test run.

Further notes

coverage/ is now gitignored and excluded from Prettier, since Vitest's coverage reporter didn't exist as an output before this change.

[JuanGalilea]

how exactly is this a safePushData?
The only thing i see here is it turning dataset validation errors into NonRetryableError but no healing or retrying with healed inputs like the other one.

Also, the reasoning behind merging them is kinda questionable. Wouldn't this be a prime target for some Partial application? all pushData's have the exact same signature, and safePushData conveniently takes it as an argument.

Couldn't it be done as partial application on your consumer?

type DatasetParameters = Parameters<typeof safePushData<DatasetItem, PushDataOutput>>
export const pushDataToDatasetX = (data: DatasetParameters[1], options: DatasetParameters[2]) => safePushData(Dataset.pushData, data, options);

And then you use pushDataToDatasetX whenever you want to push there? You also get type safety on the call location, which you don't get on the current solution.

All of this also gets rid of the peerDependencies, which is a plus in my books.

If the intent is only to turn the data validation errors into some other one, this could be done with some Higher order Function or something, without relying on this library to do the pushData or anything

[JuanGalilea]

after some nice discussion with @yaroslav-tykhovetskyi-apify we got to it kinda doesn't matter as long as its in a google-teams namespace.

Although i still dont like the purpose of the function 😅

[JuanGalilea]

these should be tilde, not >=

[radimkvet]

well, too late for those, but maybe they can be implemented in different PR.

[radimkvet]

And we can also do it here:

function safePushData<T extends object>(
data: T | T[],
options: {alias: never, eventName: string}
)

This way, we will explicitly say "we do not support those two together"

[radimkvet]

Since we do not support the two options together, we can be more explicit in the type, so the type system tells us we are doing something wrong:

function safePushData<T extends object>(
data: T | T[],
options: {alias: string, eventName: never}
)