[examples] Typescript

[lorenzofox3]

A thread where we can discuss the set up in the examples directory.

can you review the node-ts example and let me know your first impressions. Thanks !

[mindplay-dk]

Checked it out and took it for a spin. 🙂

Regarding dev, what's causing it to clear the screen after startup? I couldn't figure it out - there's no clear command in any of the npm scripts, so I don't know what's causing that. But it was a bit jarring. All this console output, no chance to read it and understand what happened, concerned if there were any warnings in there. It would be good if that didn't happen.

Also regarding dev, I have tried to use concurrently many times in the past, and it has never worked properly for me, because of this issue - it fails to shut down any of it's child tasks, so after running dev and pressing CTRL+C, I had a list of 8 hanging processes. This means I have to find them and shut them down one at a time, before I can launch again, since some of them will keep locks on files they're trying to write to, and so on. This happens on WSL1 and WSL2 on Windows, and under native node for Windows, since 2018 - reportedly happens to some people on Docker as well, and it doesn't look like it's been addressed. npm-run-all looks somewhat more popular these days, maybe that would work better?

Regarding build, I'm not sure if building with tsc is really a realistic scenario anymore?

The majority of real-world projects generally use webpack for browser-based projects, or rollup for libraries. In either case, this adds complexity, since, first of all, bundlers modify the code - with mangling or tree-shaking, which most real-world projects use, I think it's important we test the compiled output and not just the sources.

As far as I know, almost nobody uses the tsc compiler for anything other than type-checking. Type-checking is typically done with an e.g. test:type-check command that runs e.g. tsc --noEmit as part of the test. The actual compilation is usually done by babel integration with e.g. webpack or rollup.

I'm honestly an idiot when it comes to bundlers. I always end up with something weird and messy that just barely holds together with duct tape. (Maybe that's just the bundler experience? haha.)

With regards to test:coverage, this appears to have some of the same problems I had with c8. I commented-out both assertions in test/specs/is-even.ts and got the following report:

-------------|---------|----------|---------|---------|-------------------
File         | % Stmts | % Branch | % Funcs | % Lines | Uncovered Line #s
-------------|---------|----------|---------|---------|-------------------
All files    |     100 |      100 |   66.67 |     100 |
 src         |     100 |      100 |   66.67 |     100 |
  index.ts   |     100 |      100 |      50 |     100 |
  is-even.ts |     100 |      100 |     100 |     100 |
  is-odd.ts  |     100 |      100 |     100 |     100 |
 test        |     100 |      100 |     100 |     100 |
  index.ts   |     100 |      100 |     100 |     100 |
 test/specs  |     100 |      100 |     100 |     100 |
  is-even.ts |     100 |      100 |     100 |     100 |
  is-odd.ts  |     100 |      100 |     100 |     100 |
-------------|---------|----------|---------|---------|-------------------

I don't know why it's reporting coverage of the test-files themselves, and I was unable to configure it's filter settings to work around this. My only clue was this issue, which seems to suggest it just doesn't work like you might expect:

It seems include/exclude options have no effect on coverage collection, instead it only controls coverage reporting. Once I moved the --include index.js to the c8 report it produced the expected report.

That fix didn't work for me though.

I think maybe nyc is the safer bet for code coverage? It's the de-facto standard - and although I like the idea of something simpler, perhaps c8 is not mature or maintained enough to work reliably for every case?

Regarding dev:pta and the pta related scripts, this is an alternative setup with pta instead of just zora, is that correct? So this project is like a "two in one" with two different setups? It might be better to break them apart. Or just decide if you want to use one or the other. (Perhaps pta, being a separate project, should have it's own examples folder?)

Also regarding pta, it emits some errors:

[test] [nodemon] restarting due to changes...
[test] [nodemon] starting `node -r source-map-support/register node_modules/.bin/pta dist/test/specs/is-even.js dist/test/specs/is-odd.js`
[test] (node:768) UnhandledPromiseRejectionWarning: TypeError: hold is not a function
[test]     at file:///mnt/c/workspace/zora/examples/node-ts/node_modules/pta/src/bin.js:64:3
[test] (Use `node --trace-warnings ...` to show where the warning was created)
[test] (node:768) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag `--unhandled-rejections=strict` (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 1)
[test] (node:768) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

This could be due to the fact I haven't updated my node in a while? It's v14.4.0. If the project or (more likely) some of it's dependencies require a newer version, they should probably be specified using engines.

Oh man, I feel like I'm dumping a ton of work on you. This stuff is so hard to set up. I'm on vacation right now, but I might be able to jump in and try to help next week, maybe we can figure it all out together.

I'll be honest, I've never even seen a webpack or rollup project with both code and tests written in TS, built using babel, with code-coverage properly set up, source-maps, minification, and so on. I literally have not been able to find a reference project that has everything. Every boilerplate I can find is missing one thing or another, every project is too.

On top of that, now esbuild is here, and I've been trying to use that, because man I want that speed - but I'm just about ready to give up on that and revert to either webpack or rollup, because my project needs babel to target IE11, which just isn't practical with esbuild right now. (I would basically have to apply webpack or rollup with babel to the output from esbuild, which basically means esbuild isn't really doing anything very useful that webpack or rollup couldn't just do.)

I would love to solve this. I'm sure it must be possible, but dang this stuff is complicated. 😅

[lorenzofox3]

oh, thanks for the feedbacks !

Regarding dev, what's causing it to clear the screen after startup? I couldn't figure it out - there's no clear command in any of the npm scripts, so I don't know what's causing that. But it was a bit jarring. All this console output, no chance to read it and understand what happened, concerned if there were any warnings in there. It would be good if that didn't happen.

Do not know about that one. It seems, starting tsc in watch mode clear the console first (you can try by running npm run build:watch alone). I have not much control on that one:

Also regarding dev, I have tried to use concurrently many times in the past, and it has never worked properly for me, because of this issue.

Ok switched to npm-run-all

The majority of real-world projects generally use webpack for browser-based projects, or rollup for libraries. In either case, this adds complexity, since, first of all, bundlers modify the code - with mangling or tree-shaking, which most real-world projects use, I think it's important we test the compiled output and not just the sources.

Not sure that would be relevant for a non browser project like this one (simple node library written in TS), but that could be a new recipe.

With regards to test:coverage, this appears to have some of the same problems I had with c8. I commented-out both assertions in test/specs/is-even.ts and got the following report:

That is actually the correct output: src/is-even.ts is basically a function declaration which gets loaded anyway by src/index

import isEven from 'is-even';

export default isEven as (input: number) => boolean;

If you wish to see a difference, you'd better comment out the is-odd specs. Which gives you the following coverage (with the html reporter):

The declaration is indeed ran but not the implementation.

I have fixed the command to measure the source files only 👍

------------|---------|----------|---------|---------|-------------------
File        | % Stmts | % Branch | % Funcs | % Lines | Uncovered Line #s 
------------|---------|----------|---------|---------|-------------------
All files   |     100 |      100 |     100 |     100 |                   
 index.ts   |     100 |      100 |     100 |     100 |                   
 is-even.ts |     100 |      100 |     100 |     100 |                   
 is-odd.ts  |     100 |      100 |     100 |     100 |                   
------------|---------|----------|---------|---------|-------------------

I think maybe nyc is the safer bet for code coverage? It's the de-facto standard - and although I like the idea of something simpler, perhaps c8 is not mature or maintained enough to work reliably for every case?

That would be a good idea anyway to use nyc as the other recipes already use c8

Regarding dev:pta and the pta related scripts, this is an alternative setup with pta instead of just zora, is that correct? So this project is like a "two in one" with two different setups? It might be better to break them apart. Or just decide if you want to use one or the other. (Perhaps pta, being a separate project, should have it's own examples folder?)

That is just an alternative test runner to node itself. It used to require syntax adaptation but that is not the case anymore so that is basically an alternative on how to run the test suite:

node dist/test/index.js
node -r dist/test/specs/*.js
pta dist/test
for f in $(find ${@:-dist/test/specs} | grep 'js$'); do echo "require('$f')";done | node
tape dist/test/spec/*.js

Are all different ways to run the same test suite. The beauty of the UNIX philosophy :)

(I have added it to the other recipes as well)

This could be due to the fact I haven't updated my node in a while? It's v14.4.0. If the project or (more likely) some of it's dependencies require a newer version, they should probably be specified using engines.

This is correct (node v15 at least is required).

Thanks for the feedbacks, I'll add new recipes for the browser pretty soon

[mindplay-dk]

It seems, starting tsc in watch mode clear the console first

Looks like people complained about this too much, so they locked the issue. 🤦‍♂️

[lorenzofox3]

well at least, the thread you mentioned has the solution: "tsc --watch --preserveWatchOutput" :D

[mindplay-dk]

Ha, I don't know how many things I searched for in the docs, but I didn't find that one 😉