Package manager CI action

[Eomm]

Fix #1107
A run of this action here: https://github.com/Eomm/pino/actions/runs/1190604660

This PR requires a todo list to recap its status:

pnpm

• no issues ✅ flaky test on win and node 16: disabled coverage to let it works

yarn

• yarn@2 at this time, it triggers an error when the typescript module is higher than 4.3.2. Asking to reopen this issue [Bug] Cannot install typescript 4.3.2 with yarn 2 / node_modules linker yarnpkg/berry#2935 . A temporary solution is to stick the TS module version.
• yarn@3 / PnP must skip the test that create at runtime a node_module/transport package. This happens because the module does not exist during the installation phase and it is not packaged. Not sure it is a valid check. Asked help here
• yarn@3 / PnP does not works withing pino-elasticsearch. This must be supported to be PnP compatible.
• `yarn@3 / PnP: disabled typescript test due [Bug?]: internal module types not loaded yarnpkg/berry#3394

deep down on yarn@3 / PnP

The pino-elasticsearch issue is caused by the yarn's require.resolve() resolution that produces a string like this [...]cache/pino-elasticsearch-npm-6.1.0-0c03079478-6915435172.zip/node [...] (note the zip file).

This string is provided as fileName parameter to the thread-stream module:

https://github.com/pinojs/thread-stream/blob/main/lib/worker.js#L18

that throws the error:

+ENOTDIR: not a directory, stat '/Users/mspigolon/workspace/pino/.yarn/cache/pino-elasticsearch-npm-6.1.0-0c03079478-6915435172.zip/node_modules/pino-elasticsearch/lib.js'

Yarn supports this zip path out of the box (monkey patching it) but it does not support the import ESM loader.
Reference: yarnpkg/berry#638 and there is a draft PR to support it yarnpkg/berry#2161

So, to solve the PnP support issue, I see two main paths:

1. update the thread-stream module to support yarn zip path using the @yarnpkg/fslib module.
2. wait for the feat(pnp): experimental esm support yarnpkg/berry#2161 but I'm not sure it will work because the import is executed by the worker thread and I doubt it is monkey patched

[merceyz]

So, to solve the PnP support issue, I see two main paths:

A third option would be to fall back to require if import fails

but I'm not sure it will work because the import is executed by the worker thread and I doubt it is monkey patched

I haven't tested but it should work, the Worker is supposed to inherit the options from the parent

wait for the yarnpkg/berry#2161

That PR is mostly blocked by Node, they unflagged ESM before the loader API was ready

[mcollina]

I like

A third option would be to fall back to require if import fails

a lot.

I'd prefer not to add that additional dependency, but I'm also ok to add it if it's the only option.

[merceyz]

I'd prefer not to add that additional dependency, but I'm also ok to add it if it's the only option.

Adding it wouldn't help much, you can read the file by using the fs module but import can't without yarnpkg/berry#2161

[merceyz]

I meant you should do this regardless of what is running and get rid of the manual symlinking

[mcollina]

doing the same with npm across multiple node version is not that easy.

[merceyz]

With npm you can use the file: protocol which has been supported since 2.0.0
https://docs.npmjs.com/cli/v7/configuring-npm/package-json#local-paths

[Eomm]

Quick update:

• yarn/pnp tests are green, the typescript tests are failing to this issue [Bug?]: internal module types not loaded yarnpkg/berry#3394
• pnpm: there is one flaky test on Node v16 I'm working on

[mcollina]

I'm ok in landing this without typescript support if it's feasible.

[merceyz]

Suggested change

	# see https://github.com/yarnpkg/berry/issues/2935#issuecomment-911299992
	yarn add --dev typescript@~4.3.2

We've released the fix for this issue

[Eomm]

Thanks

To avoid this issue for future typescripts minor releases, where could we read the last working version integrated?

[merceyz]

We don't have it documented anywhere, we try to update the patch as soon as they make a new release. Also TypeScript doesn't follow semver so their minor is actually a major release

[Eomm]

TypeScript doesn't follow semver so their minor is actually a major release

For this reason, the pino's maintainer may evaluate to pin the dep to ~4.4.0 so it will be dependabot to update it and trigger the new error for new minor changes

[merceyz]

Suggested change

yarn add --dev typescript@~4.3.2

[Eomm]

PR ready

Updated first post accordingly.

for this issue

pnpm: there is one flaky test on Node v16 I'm working on

I had to disable the coverage since this test was starving.

What I found is that:

• pnpm spawn tap
• tap spawn a coverage instance and read the stdout
• a tap test spawns a process
• the process spawns a worker_thread
• the tap test doesn't receive any close event

I did not investigate further

pino/test/transport.test.js

Lines 372 to 382 in f712a52

	test('stdout in worker', async ({ not }) => {
	let actual = ''
	const child = execa(process.argv[0], [join(__dirname, 'fixtures', 'transport-main.js')])
	child.stdout.pipe(writer((s, enc, cb) => {
	actual += s
	cb()
	}))
	await once(child, 'close')
	not(strip(actual).match(/Hello/), null)
	})

[mcollina]

I think it might be too much to run this for every PR, those are a lot of tests. Maybe could we just run them.

As an example, we run this only on master: https://github.com/fastify/fastify/blob/main/.github/workflows/package-manager-ci.yml#L3-L6

I would also run this only on Node.js v14.

[mcollina]

lgtm

[github-actions]

This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.