I'm trying to switch from ts-node. To narrow down the issue I've deleted basically everything from my project

First I've built uni in my cloned copy at ~/dev/uni

My code is this branch here: https://github.com/AvenCloud/cloud/tree/uni-testing

I attempt to run ~/dev/uni/uni run lib/server/server.ts, and I see this unexplainable error- my code has no reference to "main"

At an earlier time, I saw a lib_uv error(!). But that was before I stripped down my reproduction example.

Usually I specify a custom tsconfig.json (tsconfig.server.json, while nextjs uses tsconfig.json).. and I couldn't figure out how to do that with uni.

I'm really chuffed about this repo. Currently, I'm learning golang and wanted to contribute to uni to expand my knowledge and help that amazing repo. Are there any guidelines and requirements to contribute?

Hi man, this PR is a feature proposal. The mixed dependence is a interesting proposal but, by my self, I prefer yarn workspaces.

But configure and manage a Yarn workspace with Typescript is boring. That proposal use the simplicity of uni.yml to configure a entire Yarn Workspace with TypeScript, Jest and Lint by replacing index property to folder property. All of your code still compatible.

All unis created files like package.json, tsconfig, jest.config, eslintrc files are in .gitignore because uni.yml will generante them

things to do:

• [ ] A initoption to guid developer create uni.yml
• [ ] Allow tsconfig.json settings changed by dev
• [ ] Options to configure importante parameters like minimal test coverage (currently is fixed in 90%)
• [ ] more uni tests and examples
• [ ] husky
• [ ] ...

I'll continue helping that amazing project. I hope you like that idea.

Extra: This PR also have VSCode devcontainer suggestion. Maybe itcan facility bring new contributors to uni team.

Closes #6

@BenElgar Could you please give this branch a try and make sure that (A) it does what you expect it to do and (B) it doesn't break existing run/watch/build use cases? If so, feel free to merge & upgrade our dependency on unirepo in the other Deref repo.

This PR does 3 things:

• Cause the child process to be stopped with SIGTERM instead of SIGKILL. SIGKILL is still sent if the process has not stopped after a fixed period.
• Start the child process in its own process group so that stopping the child will also stop any of its owned processes.
• Intercept SIGKILL/SIGTERM in uni itself and trigger a shutdown of its child process

Resolves #10

When uni exits or reloads the child process on rebuild, it should try to terminate the process with a SIGTERM rather than a SIGKILL in case there is any cleanup that needs to happen. Additionally, it should not orphan any processes started by the subprocess itself.