KyleJune
Coverage for child processes
Also if you want to spawn a server for use in multiple tests, put it in a beforeAll and assign it to a variable in the parent describe, then
child.kill(); await server.status; in the afterAll to get rid of it. My example in this help thread was using explicit resource management, so it was automatically killing the process.10 replies
Coverage for child processes
If anyone else comes across my screenshot example and tries using it, I found one flaw with it. For some reason, no additional requests would get handled after the first if you were to try to make multiple requests to the server that was started. I found it was related to how the stdout stream was getting cancelled. If you change the for loop to use
stdout.values({ preventCancel: true }) instead of stdout, the child process will keep handling requests until it is done.10 replies
Coverage for child processes
Oh nice. Good to see there is an issue for it. I was mainly looking to do it to cover code paths that are only triggered when files conditionally do work depending on import.meta.main being true. Otherwise those lines will never get touched by tests. The latest update does add a way to ignore those lines, but it would be nice to be able to cover them.
It would probably be useful for testing cli tools and their output. With that flag, people would be able to spawn child processes for the cli script with different args to test different code paths. Without it, you would need to export the functions used in the cli script to be able to test their behavior. I've done that before by having the cli code in an exported function like
export function run(args) { ... } then at the end add if (import.meta.main) { run(Deno.args) } so that that function is automatically called with deno args if the script is called directly. Then in tests you call it with fake arguments.10 replies
unsupported lockfile
Delete lock file. I think errors like that happen when switching from DENO_FUTURE being 1 to 0. Your build is running with it as 1, upgrading your lock file, then your other commands are running without it set, and it doesn't recognize or know how to handle the newer lock file format.
10 replies
Deno LSP + React + TypeScript + Vite (--node-modules-dir)
If you want to use esbuild but not my framework, check my frameworks build.ts file to see the options to use for esbuild. You need to use the esbuild deno loader for esbuild to work well with deno. I think the platform and format options are needed too.
22 replies
Deno LSP + React + TypeScript + Vite (--node-modules-dir)
The react.d.ts file for getting types to work in deno feels kinda awkward, wish we had something more like node where you can just include the types in your configuration file like you can with package.json
22 replies
Deno LSP + React + TypeScript + Vite (--node-modules-dir)
I don't use vite, I use esbuild instead. I have no issues with using react, even have SSR working. Here is an example including a react.d.ts file, you could copy that into your own project.
https://github.com/udibo/react-app-example
Here is the framework I wrote that the example is using. I'm still working on writing the guides for it.
https://github.com/udibo/react-app
22 replies
@deno/emit's transpile with JSR
Just create a getBuild function and have it generate the build files to memory. I believe there is a esbuild configuration option for that, which fresh used. Then if a request comes in for one of them, have it wait until the build files were generated by esbuild before responding to requests for the build files. If someone connects before the build finishes, they will just have a longer request time.
15 replies
@deno/emit's transpile with JSR
Yea I know how you could but I don't think you understand, "no build" still had to build your app, you just didn't get to see it happening. It happened everytime you start your server. "no build" was more like "build included" since it built the app on every run instead of only when needed.
15 replies
@deno/emit's transpile with JSR
App is slower without a build step. That's because each time the process restarts, it needs to regenerate the build before it can start handling requests for the build artifacts. The documentation says you can make the server command automatically restart itself by adding the --watch flag. The app would still need to be rebuilt for changes. Before it was just hidden because it would generate the build internally when the build files are requested. It's still being built with esbuild. Cold process startups are now quicker because of the build step not needing to run every time.
15 replies