[WIP] Browser support #887
Conversation
Running AVA in browser environment won't allow API to execute file system operations, so file searching (globbing) needs to be extracted. After this change, API expects a set of already resolved, absolute paths.
| avaFiles = AvaFiles; | ||
|
|
||
| avaFiles.prototype.findTestFilesSync = function () { | ||
| return this.files; |
There was a problem hiding this comment.
Because API expects resolved paths, findTestFilesSync needs to be stubbed to return "input" files without changes, in order to easily check them in tests. Otherwise, findTestFilesSync would return empty array.
|
@vdemedes - mind sharing where you are going with this? There are lots of different ways to attack browser support, and we probably should all agree on the best way. For instance, in my mind |
|
I agree with @jamestalmage here. Let's continue the discussion in #24 (comment)? |
Note, this is an internal flag and is not supposed to be exposed to end users. It's used only when test files were previously precompiled, to avoid double compilation and caching.
When `globals.setTimeout` or `globals.clearTimeout` is called with `globals` context, browser (at least Chrome) throws "Illegal Invocation" error. If those functions are called with `null` (global context), errors are not being thrown.
|
I pushed browser support work I've done, so that you can get a glance. To test it out:
|
|
Implementation and usage details: #24 (comment). |
| return api.run([path.join(__dirname, 'fixture/ignored-dirs/fixtures/test.js')]); | ||
| }); | ||
|
|
||
| test(prefix + 'test file in helpers is ignored', function (t) { |
There was a problem hiding this comment.
Lots of tests being deleted here. Many of which guard specific regressions. If the intent is to reimplement later, I would prefer skipping instead:
test('tilte', { skip: true }, function (t) {
...
});There was a problem hiding this comment.
Those tests are not deleted, they moved to ava-files.js tests, which covers these cases.
|
Some thoughts after an initial review: I don't think we should try to run the API in the browser. Instead, we should just be reimplementing There is also already a whole lot to review for a single PR. I would like to see an incremental approach. I think the first step should be creating a build/bundle tool that packages a single test with browser safe versions of all the child process dependencies. I don't think |
Why? I had no issue with doing that. |
| @@ -479,18 +480,6 @@ function generateTests(prefix, apiCreator) { | |||
| }); | |||
| }); | |||
|
|
|||
| test(prefix + 'search directories recursively for files', function (t) { | |||
There was a problem hiding this comment.
I do not see this test replicated anywhere.
We have efforts underway to bring watcher into the API, and simplify The less complexity we push into the browser, the better.
It's not so much a matter of whether or not it's possible, but rather if it is a good idea. It's definitely adding complexity. I think it would be better if we started trying to make a browser fork that behaves like a |
Is there a discussion/issue/pr that I missed?
I don't see how it adds more complexity. I'm not modifying API in any way, it's good to work in the browser 1:1, unchanged. As I mentioned previously, I was trying to reuse as much as possible. I don't want to rewrite AVA core for browsers. Instead, the plan was to replace node-dependent parts with browser-compatible ones. What makes it a bad idea? Do you have specific arguments against doing this? |
#533 (comment)
Not suggesting that. I'm suggesting you rewrite less than you have.
I do not disagree with this. I just think we could get there simpler if we sent stuff over the wire to the console instead of trying to do stuff in the browser. |
|
What's the status on this? |
|
Closing this since it's been languishing. Let's hash out our desired implementation in #24. |
Check out the commit messages, I tried to make them as descriptive as possible.
Implementation and usage details, vision: #24 (comment).
Coming soon.