[ANN] rescript-vitest v1.0.0 released

cometkim · December 12, 2022, 8:12pm

hoichi · December 13, 2022, 8:11am

Sorry to go off topic, but what is it about async/await compatibility? Is it the ReScript async/await, or the JS async/await?

cometkim · December 13, 2022, 8:36am

It’s ReScript’ async/await and Js.Promise2

DZakh · December 13, 2022, 11:14am

You might find the discussions interesting:

github.com/rescript-lang/rescript-compiler

Explore ideas about flattened types.

opened 04:23PM - 29 Sep 22 UTC

cristianoc

> Warning: these are exploratory high-level ideas. It would not be surprising to… find major holes in them. But at least there's an attempt to go beyond the surface and consider simple semantic models. ## Flattened Types We study the properties of flattened type constructors `c<->`, i.e. types whose runtime representation has the semantic property `c<c<'a>> = c<'a>`. Flattened types are common concepts in JavaScript: nullable values (or possibly undefined), and promises. Two semantic relations between types will be considered. `t1 <= t2` means that every JS value which is a runtime representation of type `t1` is a value of type `t2`; and `t1 = t2` means that both `t1 <= t2` and `t2 <= t1`. ## Equations We consider a unary type constructor `?<->` that obeys two equations: 1 `??t = ?t` 2 `t <= ?t` While equation 1 is self-evident, number 2 isn't. Consider that flattened types normally come with operations to "look inside", i.e. take a value of type `?t`, and later continue the computation with a value of type `t`. If one starts with a value of type `??t` and looks inside, then the computation expects to continue with a value of type `?t`. However a value of type `??t`, because of equation 1, also has type `?t`, so the computation must be able to continue with type `t`. And equation 2 is exactly what allows to provide a value of type `t` to a computation expecting `?t`. We will also use the injection `i : t => ?t`, the identity function, which exists because of equation 2. ## Option Instantiation The Option Instantiation also has the two equations plus: - An element `e` such that `e:?t` for any `t`, the empty element. We define a function `caseAnalysis : (?t, s, t=>s) => s` in JS as follows: ```js const caseAnalysis = (o, d, f) => { if (o == e) { return d } else { return f(o) } } ``` This is sufficient to interpret options: - `None` is `e` - `Some(x)` is `i(x)` - `switch e { | None => e1 | Some(x) => e2 }` is `caseAnalysis(e, e1, x=>e2)` What is left to define is the type constructor `?t` for flattened options. The definition is `t | undefined` i.e. it takes all the values that `t` takes plus the value `undefined`. It's clear that equations 1 and 2 hold. Plus we can pick `e = undefined`. As for `caseAnalysis` if `o : ?t` and `o == e` does not hold, than it must be that `o : t`. So the function satisfies the required type. This gives an instance of flattened options that don't require special representation for the nested case. It differs from ordinary options in that `Some(None)` is the same value as `None`. ## Promise Instantiation The Promise Instantiation has the two equations plus: - A function `map : (?t, t=>s) => ?s`. With this we can interpret flattened promises: - `FPromise.resolve` is `i` - `FPromise.then_` is `map` Before defining the type `?`, we use an auxiliary definition for JS promises. The type `Promise<t>` of JS promises is defined as the set of values that are JS promises holding values of type `t`. Each such value `v` has the property `Promise.resolve(v) == v`. Now the type for flattened promises is defined as: - `?t` is `t | Promise<t>` so it's either a JS value of type `t` or a JS promise holding a value of type `t`. Let's see how this satisfies the required equations. For equation 1, `??t` is `?t | Promise<?t>` i.e. `t | Promise<t> | Promise<t | Promise<t>>` i.e. `t | Promise<t>` because JS promises are flattened, i.e. `?t`. For equation 2, clearly `t <= t | Promise<t>`. What is left to do is to define `map` in JS, as follows: ```js const map = (p, f) => (Promise.resolve(p)).then(f) ``` To check the type of `map`, assume `p` has type `t | Promise<t>`, then `Promise.resolve(p)` has type `Promise<t>` so it's safe to apply `then` and obtain the result of type `Promise<s>` which also has type `?s`. > Note that if `p` is a string promise of type `???string`, then `f` will be passed a string, but that's OK as a string value also has type `?string` as well as `??string`. Compared to ordinary JS promise types, `?t` obeys property 2, which is what seems to protect it from issues when types are assigned to nested promises. Async/await requires no special interpretation. For example: ```res let double: ?t => ?(t, t) = async (x) => { let y = await x (y, y) } ``` compiles to: ```js async function double(x) { var y = await x; return [y, y]; } ``` Now if `x` has type `?t`, i.e. is a JS value of type `t | Promise<t>`, then there are 2 cases: - If `x` has type `Promise<t>` then `await x` has type `t` - Otherwise, x has type `t` and is not a promise, so `await x` is `x`, which has type `t`.

jmagaram · January 7, 2023, 1:16am

I’m giving this a try. When the .test.res file is changed, the underlying .test.bs.js file is updated as expected. I can look at the .bs.js file and see something like expect(4).toEqual(5) But the vitest output in the terminal still shows everything passing. I have to go into the .test.bs.js file and save it, causing a reformat, for vitest to notice the test has changed and update the results. Somehow the vitest watcher isn’t noticing when the auto-generated .bs.js file is changed. Have you seen this?

—-

I set the vitest config include property to look for the generated test.bs.js files so I don’t know why it doesn’t notice when these files change. I have to change them manually by doing a file save on them. How is your vitest configured? Is some rescript plug-in or something needed?

cometkim · January 8, 2023, 4:27pm

Nothing special in my vitest config. But I use rescript-vitest with vite-plugin-resscript

scull7 · January 9, 2023, 4:47am

When I attempt to use the vite-plugin-rescript installation instructions I’m receiving an error that the Js.Promise2 library is not found. This is using:

  "devDependencies": {
    "@jihchi/vite-plugin-rescript": "^5.0.0",
    "@testing-library/jest-dom": "^5.16.5",
    "@testing-library/react": "^13.4.0",
    "@vitejs/plugin-react": "^3.0.1",
    "jsdom": "^21.0.0",
    "rescript-vitest": "^1.0.1",
    "vite": "^4.0.4",
    "vitest": "^0.26.3"
  },
  "dependencies": {
    "@rescript/react": "0.11",
    "@ryyppy/rescript-promise": "^2.1.0",
    "react": "^18.2.0",
    "react-dom": "^18.2.0",
    "rescript": "^10.0.1",
    "rescript-webapi": "^0.7.0"
  }
}

Is this a known incompatibility?

DZakh · January 9, 2023, 6:44am

You need to use rescript@10.1.x

jmagaram · January 16, 2023, 6:42am

The watcher problem I was having fixed itself when I upgraded vitest to ^0.27.1. But now I have a different issue. Are there any special steps you need to take to install rescript-vitest to get it working? I’ve done this…

Add rescript-vitest to devDependencies in package.json
Add rescript-vitest to bs-dependencies in bsconfig.json
Configure vite.config.js to something like this…

export default defineConfig({
  plugins: [react()],
  test: {
    include: [...configDefaults.include, "**/*.{test,spec}.bs.js"],
  },
});

My tests won’t run. I get this error…

Error: No test suite found in
file /Users/.../Source/vite-experiments/vite2/src/MathTest.test.bs.js

Here is the generated test file…

// Generated by ReScript, PLEASE EDIT WITH CARE

import * as Vitest from "rescript-vitest/src/Vitest.bs.js";
import * as Vitest$1 from "vitest";

Vitest.describe("Math test suite", undefined, function (param) {
  Vitest.test("addition", 2500, function (_t) {
    Vitest$1.expect(8).toEqual(8);
  });
});

export {};
/*  Not a pure module */

Note that if I instead copy the Vitest.res file into my project src folder, as if I wrote it myself, the tests run just fine. I searched the internet for “vitest No test suite found” it looks like there are some similar bugs in the vitest repository.

cometkim · January 16, 2023, 8:24am

I’ll add a section to the README about the including files setting.

The problem you reported is probably related to the bundler.
Could you try to resolve it with refering to Dep Optimization Options | Vite?

jmagaram · January 17, 2023, 4:46pm

Sorry I barely understand the docs on Dep Optimization Options and how this could relate to the problem I’m seeing with No Test Suite found. I don’t know what to try.

jmagaram · January 18, 2023, 11:16pm

I’m porting my tests over to your bindings. I use data driven tests a lot, like test.each, and it doesn’t look like this is implemented in your bindings. I’ve started trying to write these bindings; just trying to get a bare minimum working. It doesn’t follow your current approach of functors. I’m not very familiar with vitest. I’m just trying to get something to compile. You could probably do it properly a LOT faster than me. I think we need testObject - for an array of objects - and test2, test3, test4, etc. for test case arrays of length 2, 3, 4, etc. And these need async and non-async version. And the timeout options. I’ve gotten these below to work.

module Each = {
  type test

  @module("vitest") @val
  external _test: test = "test"

  @send
  external _testObj: (
    ~test: test,
    ~cases: array<'c>,
    . ~name: string,
    ~f: @uncurry ('c => unit),
    ~param: Js.undefined<int>,
  ) => unit = "each"

  @send
  external _testArray2: (
    ~test: test,
    ~cases: array<('a, 'b)>,
    . ~name: string,
    ~f: @uncurry ('a, 'b) => unit,
    ~param: Js.undefined<int>,
  ) => unit = "each"

  @inline
  let testObject = (cases, name, f) =>
    _testObj(~test=_test, ~cases)(. ~name, ~f, ~param=Js.Undefined.empty)

  @inline
  let test2 = (cases, name, f) =>
    _testArray2(~test=_test, ~cases)(. ~name, ~f, ~param=Js.Undefined.empty)
}

jmagaram · January 23, 2023, 7:14am

I finished the bindings for test.each and describe.each. Tried creating a pull request - never done this before. Check it out.

cometkim · January 23, 2023, 9:28am

Sorry, I meant vitest config something like:

// in your vitest.config.ts or vite.config.ts
import { defineConfig } from 'vitest/config'

export default defineConfig({
  test: {
    deps: {
      inline: true, // this
      fallbackCjs: true, // or this
    },
  },
});