refactor: Make (most) modules local

[Zearin]

Note: I didn’t spend a lot of time on this, and I didn’t ask ahead of time, so feel free to reject. 🤓

I thought it would be better to have hTest’s imports not depend on whether the user is connected to the internet.

This doesn’t 100% fix that, because of imports from Bliss v2. But we can always fix that when Bliss v2 is officially released.

[netlify]

✅ Deploy Preview for h-test ready!

Name	Link
🔨 Latest commit	8a988a4
🔍 Latest deploy log	https://app.netlify.com/projects/h-test/deploys/6953f7094156c10008bdb120
😎 Deploy Preview	https://deploy-preview-115--h-test.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[Zearin]

@LeaVerou Any chance for this PR?

[Zearin]

@DmitrySharabin Would you be willing to take a look?

[DmitrySharabin]

Hey @Zearin,

We actually already had all the classes in one repo before we extracted hTest HTML into a separate repo. I’m not sure if it's worth bringing it back.

I’m not familiar with your workflow, but Requestly might help when you need to use local versions of files instead of fetching them from the internet—specifically, redirects. Will it be enough for your use case?

[Zearin]

We actually already had all the classes in one repo before we extracted hTest HTML into a separate repo. I’m not sure if it's worth bringing it back.

Oh! I hadn’t seen that one yet. Thanks for the heads up!

I’m not familiar with your workflow, but Requestly might help when you need to use local versions of files instead of fetching them from the internet—specifically, redirects. Will it be enough for your use case?

Although lots of my other PRs were born out of my own use case, this one wasn’t.

It just seems odd to me that dependencies need to fetched from the web for a testing tool—even a web testing tool.

Suppose someone was having connectivity problems. Do they know it’s a problem with hTest? Is it a problem with the code they’re testing? Or with the tests they wrote?

If network connectivity were not a requirement, all those questions go away.

I hadn’t realized there was entire PR to separate out the HTML code, but… it’s not actually separate. For example: RefTest (and more) is not really specific to the htest-html repo. I was using JS-first tests for my DOMRect experiments, but DOMRect needs the browser environment. So, even JS-first testing (sometimes) needs code from the htest-html repo.

In the PR you reference (#90), it’s listed as closing Issue #55. I read that, and the following sentence written by @LeaVerou stood out to me:

OTOH it's been a while since I've looked at that part of the code, and it may turn out it's hard to disentangle.

Well, you pulled it off, in that hTest will still run if network isn’t an issue. But there are parts of the world where it is. Rural areas for one. The awesome SVG & Web Accessibility instructor, Sara Soueidan, lives in Lebanon, where electricity and/or network connectivity can just cut out at certain times.

Does any of this make sense?

It’s not my intention to be difficult. I just think this is a potential issue for hTest users that doesn’t technically need to exist.

[DmitrySharabin]

All good points. And I'm not against any of them. However, I'm not sure bringing everything in one place is the right solution.

I was using JS-first tests for my DOMRect experiments, but DOMRect needs the browser environment. So, even JS-first testing (sometimes) needs code from the htest-html repo.

The need to use the hTest HTML renderer to run JS-first tests is a consequence of the main hTest limitation (at least for now)—hTest desperately needs a test runner that supports running tests in headless browsers. At the time when we have it, you don't need to rely on the hTest renderer to run your tests. And the need to fetch resources from the internet will be automatically resolved. We should probably prioritize implementing that feature.

I hadn’t realized there was entire PR to separate out the HTML code, but… it’s not actually separate. For example: RefTest (and more) is not really specific to the htest-html repo.

Even more: the RefTest class uses utility functions and hooks from hTest. So, both parts of hTest are indeed entangled. The main reason the two parts of hTest are separated is that they allow defining tests for different use cases in distinct ways. And RefTest is actually very specific to hTest HTML. That's why when we use it in the hTest renderer, we face all its limitations, e.g., it doesn't support nested tests.

But I think we can separate hTest and hTest HTML even further if we move the hTest HTML renderer to a separate repo (and make it a separate package?). In that case, we can improve it so it effectively solves its main task—rendering JS-first tests (and not serve as a workaround to run DOM-specific JS-first tests in the browser). @LeaVerou, what do you think?

It’s not my intention to be difficult. I just think this is a potential issue for hTest users that doesn’t technically need to exist.

You are not difficult. On the contrary, you are pushing (in a good sense) us make hTest awesomer. And we are discussing possible ways to do it. So, thank you! 😊

P.S.

But there are parts of the world where it is. Rural areas for one. The awesome SVG & Web Accessibility instructor, Sara Soueidan, lives in Lebanon, where electricity and/or network connectivity can just cut out at certain times.

Believe me, I clearly understand it. Even though I don't live in Lebanon, outages at my place aren't that rare. 😅

[LeaVerou]

@Zearin That makes total sense. I've lately been working on a better way to manage client-side dependencies without remote requests. It's not released yet but you can try it out here: https://github.com/nudeps/nudeps
I wonder if it could help here too.