Migrate from Jest to Uvu

[win0err]

I suggest to use Uvu instead of Jest. It's stable, many popular packages are using this utility: Browserslist, PostCSS, etc.

Jest vs. Uvu comparison

Installation speed

Jest:

$ npm i --force
...
added 900 packages, and audited 901 packages in 30s

Uvu:

$ npm i

added 508 packages, and audited 509 packages in 7s

node_modules size

Jest:

$ du -sh node_modules/
310M	node_modules/

Uvu:

$ du -sh node_modules
286M	node_modules

Testing time

Jest (2,5 sec.):

$ npm run test
...
Test Suites: 1 passed, 1 total
Tests:       13 passed, 13 total
Snapshots:   0 total
Time:        2.514 s, estimated 4 s
Ran all test suites.

Uvu (~1 ms, not second):

$ npm run test
...
  Total:     13
  Passed:    13
  Skipped:   0
  Duration:  1.05ms

[ellenhp]

I'm open to doing this as long as it works well with Quasar and doesn't burn any bridges. Quasar recommends Jest and I don't want to stray too far from their way of doing things because I do want to build mobile apps with Cordova eventually, and the promise of Quasar is that they make it easy to do so.

[ellenhp]

Also curious if package-lock.json it necessary for yarn to work? I didn't think it was, and I'd prefer to avoid checking in two different lockfiles.

[win0err]

I'm open to doing this as long as it works well with Quasar and doesn't burn any bridges. Quasar recommends Jest and I don't want to stray too far from their way of doing things because I do want to build mobile apps with Cordova eventually, and the promise of Quasar is that they make it easy to do so.

1. It will work, of course. It's just a unit testing framework. A very lightweight framework. For example, it doesn't have expect.arrayContaining.

const odd = [1, 3, 5, 7];

test('just an example', () => {
  expect(odd).toEqual(expect.arrayContaining([3, 5]));
});

// Could be rewritten as
test('just an example', () => {
  is(
    [3, 5].every(n => odd.includes(n)),
    true,
  );
});

To mock & spy functions nanospy will perfectly fit (it's also used in projects like PostCSS or Browserslist). For example, @vue/test-utils will work fine with Uvu.

2. About Cordova, from the official website:

Cordova wraps your HTML/JavaScript app into a native container which can access the device functions of several platforms.

The application stays the same web-application (not native) with some additional APIs provided by Cordova. That's it.

P.S. It will be very laggy on cheap smartphones. That's why React Native or Flutter exists. Just warning you.

[win0err]

Also curious if package-lock.json it necessary for yarn to work? I didn't think it was, and I'd prefer to avoid checking in two different lockfiles.

Will remove it.

Upd. ~~Done~~ Upd2. Actually done

[ellenhp]

P.S. It will be very laggy on cheap smartphones. That's why React Native or Flutter exists. Just warning you.

Until maplibre-gl-js works with React Native or Flutter gets a nice vector maps renderer, this is IMO the best way to build a single-codebase maps app. It won't be perfect but it's the best I can do I think.

edit: There are ways to shim in the native maplibre client but they're imperfect. Single-codebase maps apps isn't yet a solved problem.

[win0err]

I'm not sure about this, honestly. I read through the diff and I really do enjoy having fluent assertions. I'm more than willing to sacrifice a few megabytes on my hard drive and 1s per run for that. Are there other reasons to switch?

For PostCSS (25 test suits): time reduced from ~8.7s to ~250ms (3,380% faster), size of node_modules decreased from 150 mb to 114mb (31.578947% smaller).

I think if there's a chance to make software faster, we should take this chance :-)

P.S. https://github.com/headwaymaps/headway/pull/164#discussion_r974659228, fixed in 6268542b0d080eaa6ca093a07b2a6ae83223725c