Fix Windows CI via node+jest (as alternative to bun)

[fritx]

#154 can not be re-opened, so created a new PR with less diff change:

Goal:
Add and fix CI for Windows

Problem:
bun is not availble in Windows currently (ref: oven-sh/bun#8045, oven-sh/bun#7991).
Tried with both setup-bun (docs, failed) and powershell -c "irm bun.sh/install.ps1|iex" (docs, failed)

Solution:
For Windows, switching to npm install + jest as alternative to bun install + bun test.

Details:

• Completing the CI envs: (ubuntu, macos, windows) x (bun, node+jest)
• Making tests compatible with node+jest:
  • adding some missing is_browser detections
  • introducing es-main to detect and prevent unexpected call of getArgs (throwing on the wrong args)
  • using jest-extended to eliminate the expect.* matchers gap between bun test and jest
  • separating kit-init.test.js to run sequential, making tests passed (seems chdir is affecting the other tests)
• Making tests compatible with Windows:
  • introducing toMatchPath
  • handling some paths with path.normalize or getPosixPath

[tipiirai]

Wow. This is huge! Seems a lot of work as well. Thanks!

[tipiirai]

Hmm.. Looks like there are some conflicts. Probably relates to my recent (massive) Nuemark push. Also noticed that the front page README shows an alarming red Tests Failed message. I'm posting a link to Hacker News still..

[fritx]

Looks like there are some conflicts

Conflicts are resolved. And I've introduced jest-extended (for CI only) to avoid replacing toInclude with toContain (aka. reduce changes in this PR)

[tipiirai]

This is really an important test suite addition. But I can see one test failing so I didn't yet merge.

Thanks

[fritx]

Latest conflicts and failed tests are fixed now 😂

[fritx]

Btw, I found the error messages from jest testing is even more useful than the bun test:

from bun test:

from jest:

[tipiirai]

Awesome. Thank you!

[tipiirai]

@fritx any idea why the test runner fails with this error currently?

There is that ugly, red "failing" flag prominently visible again. Hurts my eyes.

Thanks!!

[nobkd]

@tipiirai

The tests did run on my end without any problems (apart from the node version warning): https://github.com/nobkd/nue/actions/runs/7673174907

---

It looks a little like the workflow run was accidentally cancelled on this repo... At least the second attempt:

---

The first attempt failed, probably because the correct package version was not uploaded, maybe? (and therefore missing from the package registry?) 🤷

---

Tip

You can try running it again with a completely new attempt:

(on master)

[fritx]

Looks like it is because the Test-workflow runs right after the [email protected] commits (while it was not yet published to npmjs registry). So No version matching ^0.1.1 found for specifier "nuemark" (b9a0587...638c181)

Solutions:

1. For hotfix: Can you guys pls just re-run the workflow right now (I don't have the permission). I guess it should pass since the [email protected] has been available.
2. For long-term fix: Maybe we should integrate the npm-publish process into the workflow (as another job, if the version bumps), and make it a pre-dependency of the Test-workflow. @tipiirai @nobkd

[tipiirai]

@fritx I re-run the workflow and now it passed! Thank you.

Integrating npm-publish would be awesome. Pushing a new version is a bit of a stress right now since I'm not very confident that everything goes well. Monorepos and deploy automation are certainly my weak areas in terms of experience and motivation.

I just made you a Nue collaborator with Triage permission. Is that enough?

btw: For some reasons I'm not notified for replies to issues. Only new ones. This (and lazyness) is why my responses take time. Need to update notification settings.

@nobkd I invited you also with Triage permission. You can both now merge pull requests among other things. Your contributions have been excellent and I have full trust that they are aligned with the guidelines. Thanks guys!

[nobkd]

Just, so you know @tipiirai

I think, the triage role only allows reviewing. It says on open PR's, that you need write permission to be able to merge PR's.

---

Yes, triage has only read access and allows managing issues / discussions and can review PR's effectively.
So no merges from us currently 😉

See: https://docs.github.com/en/organizations/managing-user-access-to-your-organizations-repositories/managing-repository-roles/repository-roles-for-an-organization

Note

Read: Recommended for non-code contributors who want to view or discuss your project

Triage: Recommended for contributors who need to proactively manage issues, discussions, and pull requests without write access

Write: Recommended for contributors who actively push to your project

Maintain: Recommended for project managers who need to manage the repository without access to sensitive or destructive actions

Admin: Recommended for people who need full access to the project, including sensitive and destructive actions like managing security or deleting a repository

(Alert blockquotes syntax reference)