jessealama / decimal128

JavaScript userland partial implementation of IEEE 754 Decimal128 decimal floating-point arithmetic
BSD 2-Clause "Simplified" License
19 stars 8 forks source link

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

Open amoshydra opened 6 months ago

amoshydra commented 6 months ago

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 commented 6 months ago

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:

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 - https://github.com/jessealama/decimal128/pull/95

amoshydra commented 6 months ago

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 commented 6 months ago

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 commented 6 months ago

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 commented 6 months ago

(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](https://github.com/jessealama/decimal128/pull/93#issuecomment-2047790788)*) itself.

For this issue, I believe an update to the README should be sufficient.
jessealama commented 6 months ago

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.