chore: set up initial actions & docs

[JakobJingleheimer]

No description provided.

[bmuenzenmeyer]

just throwing this previous conversation here nodejs/release-cloudflare-worker#132 - it's not a blocker, but i honestly dont know how to manage this sort of fragmentation across the project - perhaps it doesnt matter

[JakobJingleheimer]

I think some fragmentation is fine. I think it's more important to keep standards similar. How they are enforced is an implementation detail, and the existing modus operandi of the project is, without a compelling reason to the contrary, that's author's choice.

ESLint being "in the family" is maybe a compelling reason, but i think not a clear-cut one.

I don't have much preference though. ESLint has been fine when I've used it before. I only tossed in biome here because of the reasons Augustin mentioned.

[AugustinMauroy]

Need to add code snippets about how to run test and how to write a test.
Take example on nodejs.org repo we had done huge work to have something really explicit

[JakobJingleheimer]

Good idea!

This PR isn't finished btw. Just as much as I could get done last night. But it's ready for input/discussion 🙂

[AugustinMauroy]

Should we have commit hooks ?

[AugustinMauroy]

this should be done in sub steps ? I'm no sure.
@bmuenzenmeyer is more of an expert on this than I am

[JakobJingleheimer]

I think we need to set an additional property so that VS Code doesn't change d.ts → .js when it updates imports. I don't recall what the config prop is though.

[AugustinMauroy]

I've no idea, but I think this behaviour is gone now, but not for sure.

[JakobJingleheimer]

Definitely not gone. It happened to me like yesterday.

[JakobJingleheimer]

Should we have commit hooks ?

I think no: those can get hella annoying. If a user wants to commit code that will fail, that doesn't hurt anything, so let's not get in the way—maybe they have a good reason (like sharing something incomplete).

[JakobJingleheimer]

should we include or exclude this file ?

I think include

[JakobJingleheimer]

Hmm, I'm not sure why this works fine locally but fails in CI

> [email protected] test:unit
> node --no-warnings --experimental-test-coverage --test-reporter=lcov --test-reporter-destination=./coverage.lcov --test-reporter=spec --test-reporter-destination=stdout --experimental-test-module-mocks --import './build/snapshots.ts' --test --test-coverage-include='recipes/**/*' --test-coverage-exclude='**/*.spec.m(j|t)s' --test-coverage-lines=0.8 './packages/*/*.spec.m(j|t)s'

node: bad option: --test-coverage-include=recipes/**/*
node: bad option: --test-coverage-exclude=**/*.spec.m(j|t)s
node: bad option: --test-coverage-lines=0.[8]

https://github.com/nodejs/userland-migrations/actions/runs/11986924657/job/33420496685?pr=1#step:5:9

[bmuenzenmeyer]

Hmm, I'm not sure why this works fine locally but fails in CI

it's only complaining about flags written after --test... but it's odd that the failing CI doesn't seem to exhibit a pattern across os or version.

[bmuenzenmeyer]

note

• all windows builds that are failing have this error message 't)s'' is not recognized as an internal or external command,
• all macos or ubuntu failures have the bad option messages

[AugustinMauroy]

maybe because newest version use fs.glob or something like that ?