Please use mochajs/mocha for questions! This channel is for discussions related to maintaining Mocha.
I Assetgraph we had to invent our own dumpsterfire of a syntax in order to let you declare external dpendencies in js:
'stringLiteral'.toString('url')
There are forces working against this simple proposal becasue they feel it would invalidate their much more complex proposal to be able to load css, json etc as a module, being able to consume either the raw text or an ast depending on context etc
Just wanted to mension css modules: https://medium.com/front-end-developers/css-modules-solving-the-challenges-of-css-at-scale-85789980b04f#1b8a
But the simple concept of annotating this file depends on this other file. Nope
Take all of that away, and tool interop becaomes extremely simple again
<insert scope creep meme here> 😉
This is one of my primary motivations for experimenting with pulling transpiler pipelines into the file system, so we can skip the duplicate configuration of loaders for every single tool: https://www.youtube.com/watch?v=MptY6ff4tOQ
It did not. I had a few people approach me about the idea, including some of the people from Bloomberg who put a lot of work into js module standardisation. But ultimately the fuse libraries for node were a bit young and unstable, there wasn't any multithreading, and I just didn't have any time to keep working on it
There's also this problem that some applications, like web servers, can depend on knowing the length of a file to set it in response headers. This happens by calling a stat on the file first. If the size is reported wrong, the whole http stream becomes buggy. This meant I had to switch from initiating work upon file read to do it on
stat, which also meant that the concept of work on demand was completely killed, because operating systems have all sorts of indexing services running stat calls on all sorts of files all the time. Especially freshly mounted file systems. All performance benefits from skipping work were just non-existent
I think there is multithreading in the node bindings now. And if a cache concept could be introduced that wouldn't throw away the previous work upon unmount, then maybe the file stats wouldn't a problem any more. Imagine havign your whole company running mounted file systems backed by a shared redis cache, so you essentially have completely distributed shared caching of all files across the company
Still... file system is pretty low level. A lot of calls to intercept, no?
I like the typescript concept of "hosts"
There are a fe calls, yes. But it's a reasonable amount of boiler plate. https://github.com/Munter/fusile/blob/master/lib/index.js
The dependency graph problem is separate. Related in case of frontend development, but both things would have value solved separately
require() was just a convention. Literally anything other than es modules has been completely runtime implemented or environment dependent. And even with modules, we can only include js modules, not reference anything else
My idea of
external imageUrl from './path/to/image.jpg' would work though. Because in my favorite abstraction I can go <img src="${imageUrl}">
No bundler or loader needed
A bundler might be able to add value on top, for renaming files to be content addressable for example. But not required
It could even inline:
external imageUrl from 'base64:...';
Oh boy. 7.2.0 now got a failure on the node v8 tests, the ones which are dropped in master.
see: https://travis-ci.org/github/mochajs/mocha/builds/690030122
Replicated locally.
see: https://travis-ci.org/github/mochajs/mocha/builds/690030122
Replicated locally.
cherry-picked commits: https://github.com/mochajs/mocha/commits/release/v7.2.x
Update on release issue.
We moved to
If anyone has any thoughts on this pls let me know. Im doing what I think is correct
We moved to
fs-extra v9 few months ago. v9 does not support nodejs v8. As we need to continue supporting nodejs v8 for our 7.x release branch I am downgrading that dep for this release branch.If anyone has any thoughts on this pls let me know. Im doing what I think is correct