Unable to run test due to "Error [ERR_MODULE_NOT_FOUND]: Cannot find module *.mjs"

[amoshydra]

Background

Current

> decimal128@11.2.0 test
> jest

 FAIL  tests/subtract.test.js
  ● Test suite failed to run

    Error [ERR_MODULE_NOT_FOUND]: Cannot find module 'D:\projects\repository\github.com\jessealama\decimal128\src\decimal128.mjs' imported from D:\projects\repository\github.com\jessealama\decimal128\tests\subtract.test.js



 FAIL  tests/rational.test.js
  ● Test suite failed to run

    Error [ERR_MODULE_NOT_FOUND]: Cannot find module 'D:\projects\repository\github.com\jessealama\decimal128\src\rational.mjs' imported from D:\projects\repository\github.com\jessealama\decimal128\tests\rational.test.js


 // ... repeat 12 more times

Test Suites: 14 failed, 14 total
Tests:       0 total
Snapshots:   0 total
Time:        0.434 s
Ran all test suites.

Expected

To be able to test

Reproduce

checkout to today's latest

git checkout 66a0909717894af09b3c613d77668f329dfceaf4 
npm i

npm test

[amoshydra]

I manage to resolve the issue to a certain extend,
first - rename the tests to import mts (the real file extension) instead of the transpiled one

Then:

• https://www.npmjs.com/package/jest-light-runner#using-custom-nodejs-esm-loaders - on using custom loader
• Remove --experimental-loader ExperimentalWarning as the option doesn't exist anymore / is no longer experimental nodejs/node#51196 - on how to resolve the warning

to a certain extend

I said to a certain extends because coverage still doesn't quite work yet

Here is a PR that fix the issue with running npm test - #95

[amoshydra]

I am able to fix the coverage by using ts-jest following their guide on ESM Support in https://kulshekhar.github.io/ts-jest/docs/guides/esm-support

I have created another PR at #96

Let me know what you think

[amoshydra]

After inspecting .github/workflows/push.yaml, I come to realise that npm test and npm run coverage are meant to run after npx tsc.

Perhaps this is a no issue at all right now.

The original intention was actually to make test work for #93

[jessealama]

Right, I always compile the TypeScript before running tests. Is there a better way we could document that? Should we compile TypeScript as part of running the tests? That would ensure that tests always run on the compiled JS (and wouldn't even run if there were TypeScript compile errors), but it seems a bit heavy to me.

[amoshydra]

(1)

. Is there a better way we could document that?

usually it can be documented in the README.md, i.e.

### Running test

```sh
npx tsc
npm run test
```

(2)

That would ensure that tests always run on the compiled JS

This is reasonable.

In the projects I worked with, I generally write tests to import from the source code, not from transpiled code.
My tests are also written in TypeScript and type checking is also done as part of the test.

In my opinion, testing against transpiled JS is considered much safer. Having the test fail due to TypeScript compile error is reasonable to me too.

(3)
The more I think about it, this issue doesn't warrant a code change #96 #95.
My original motivation is also best resolved in #93 (updated) itself.

For this issue, I believe an update to the README should be sufficient.

[jessealama]

To be honest, I'd love to just write my tests in TypeScript, too. The main thing, in my opinion, the transpiled JS for end-users.

[jessealama]

Is this still an issue, given the changes in #121 ?

Also, FWIW: the filenames are src/Decimal128.mts, not src/decimal128.mts. Could case-(in)sensitivity be playing a role here?