uvu is not browser compatible

[surma]

Not sure if this is intentional and there’s just a note missing in the README, but uvu/assert relies on kleur, which assumes process exists.

I’d love if I could just bundle my test suite and run it in the browser.

[surma]

I need to amend: uvu is not browser compatible as it also imports kleur. Maybe I am misunderstanding how you envision uvu being used in the browser?

[lukeed]

Hey 👋

There's a browser wrapper/extension coming that will bundle your tests for you and auto-execute them inside a puppeteer or playwright instance. Right now, all that really needs to happen is a simple process.env -> {} replacement as part of the bundle step. I was planning on adjusting kleur to include a process check, but realistically, users' tests/source/dependencies will likely have process checks too, so I'm not 100% sure what the right move is there.

As it stands, my browser-layer will use these Rollup plugins which should cover most cases:

resolve(),
commonjs(),
globals(),
builtins(),

And here's a screenshot of uvu running inside a non-headless Playwright:

AKA, it's definitely possible, but requires a little bit of effort right now (hence "compatible"). It should probably be asterisked... but the plan was to release the browser-layer soon after uvu released, except the hesitations about user-shimming has me second-guessing.

[surma]

Ohai :D

Getting bundling, shimming and puppeteering out of the box sounds great. Happy to dog-food that whenever it’s available.

[lukeed]

Cool, thank you :)

My goal is to make it so that all you have to do is modify the CLI command (add --browser [name?]) and the work is done for you. My remaining goal with the CLI is to allow you to rerun the same test files with different source modules. I have a lot of browser-worker-nodejs packages that all have the same API and should handle the same tests... I'm lazy so I'm aiming for that.

The second usage pattern is programmatic, requiring an import at the top of specific test files. I'm still playing with the API for this, but the goal is to setup/build/run specific files from within the test files. So that instead of uvu.bundle('path/to/test.js') you can do something within test.js that sets up the browser and gives you access to the Puppeteer/Playwright APIs. The CLI approach cannot allow this at all (AFAIK), which is a bummer, so I'm hoping this avenue fills that need.

[lukeed]

With kleur patched, this is all the Rollup config you need to get uvu going in a browser:

{
  input: 'path/to/test.js',
  output: {
    // suggested
    format: 'esm',
    file: 'path/to/output.js',
    sourcemap: 'inline'
  },
  plugins: [
    resolve(), // <~ @rollup/plugin-node-resolve
  ]
}

I'll circle back here once I feel reasonably confident about the official browser thingy.

[osdevisnot]

👋 @lukeed, This approach works perfect for testing in browser. Do you have any recommendation on how to get code coverage report when running uvu in browser?

[lukeed]

Hey, I'm slowly trying to design a new API that will accomodate programmatic usage – or at least make it easier. So eventually this will be easier. But until then, what I'm doing (am using playwright) is listening to the console event and parsing the output text:

const strip = str => str.replace(/\x1b\[\d{1,2}m/g, '');
const toCount = (title, line) => Number(strip(line).split(title)[1]);

// ...

page.on('console', msg => {
  let txt = msg.text();
  if (txt.includes('  Total: ')) {
    total += toCount('Total:', txt);
  } else if (txt.includes('  Passed: ')) {
    pass += toCount('Passed:', txt);
  } else if (txt.includes('  Skipped: ')) {
    skips += toCount('Skipped:', txt);
  } else if (txt.includes('  Duration: ')) {
    resolve({ total, pass, skips });
  } else {
    process.stdout.write(txt);
  }
});

If you're running directly in a browser, you'll probably have to override the console.log method directly & do the same parsing.

[osdevisnot]

This sounds great, but maybe I was not super clear before. What I am looking for is to be able to obtain istanbul style code coverage report when I run uvu in browser.

I looked at your earlier umu attempt and realized that we can use startJSCoverage API as outlined in the playwright docs

const { chromium } = require('playwright');
const v8toIstanbul = require('v8-to-istanbul');

(async() => {
  const browser = await chromium.launch();
  const page = await browser.newPage();
  await page.coverage.startJSCoverage();
  await page.goto('https://chromium.org');
  const coverage = await page.coverage.stopJSCoverage();
  for (const entry of coverage) {
    const converter = new v8toIstanbul('', 0, { source: entry.source });
    await converter.load();
    converter.applyCoverage(entry.functions);
    console.log(JSON.stringify(converter.toIstanbul()));
  }
  await browser.close();
})();

This is something that might work in user land, but I am curious if uvu is willing to include this in core or if we want to have this outside of uvu (maybe separate package as umu) or leave it to user land.

The question was really about the roadmap for uvu focused on testing in browsers and code coverage reports.

[lukeed]

Oh gotcha.

uvu will always just be the core test runner & "write the tests"-collection of utilities. It will remain agnostic to its environment, but always work as a Nodejs test runner by default.

umu will be the opinionated browser orchestration tool. Like uvu, it will have its own CLI but could also be used programmatically. It's basically a wrapper around playwright (might make this flexible) and take care of the 90% use case of what people want from a frontend-testing setup. It will also have a programmatic interface so that you could pull it into existing tests or control tabs/page-reloads/etc if desired. The idea here is that you don't like or want the done-for-you solution (umu), you can always build on top of uvu, since it should be flexible & light enough to do what you want to do.

TBH I'm not working on any frontend codebases right now, which means I'm not working on umu right now either, haha.

Until then, you could import puppeteer/playwright directly into your uvu tests & do what you need to do – including collecting coverage. There are examples of this in the repo already & there are a number of projects that are using this approach w/ uvu too.

So ya, uvu itself is nearly done, but its roadmap is:

• parallel suite execution (done)
• describe-style api (easy)
• improved programmatic api/experience
• remaining diff'ing TODOs
• timeout control (maybe)
• esm loader hook (future)
• global hooks (maybe)
• grep (maybe)

[osdevisnot]

Thank you @lukeed, this is great 🎉. I really appreciate you taking time to write that down 👍.

[tinchoz49]

Hi everyone, we have been using uvu in our company for the last five months and we are very happy with the result.

We did a browser runner with uvu support that maybe can help to someone else here 😃

https://github.com/geut/brode/tree/main/packages/brode

[gautelo]

This is the first I heard about an umu package. I found it on the npm registry (https://www.npmjs.com/package/umu), but it's link to github is dead. Was the project cancelled or did it just get moved somewhere else, getting a new name or something like that?

[lukeed]

umu isn't publicly released yet as it's going thru major drastic changes. It's not ready or stable enough for public usage, but its development is tied to the uvu refactor too (for programmatic usage)

[gautelo]

@lukeed All of this sounds great! Can't wait! :)