es6-shim
es6-shim copied to clipboard
paulmillr
Use tape and testling, instead of mocha
@paulmillr There have been a number of PRs lately that have broken tests - can we get Travis CI set up for this repo, to avoid obvious breakages?
As the repo owner, you've got to do the travis setup. I can handle travis.yml etc as necessary once that's done :-)
Absolutely not! Every browser will have a different JS engine, and each version might fail in subtly different ways. To be a proper shim, it needs to work in as close to 100% of environments as possible.
PhantomJS is just a headless webkit. That probably adds minimal value, above the node tests (since both are v8-based). It would be better to use something which could actually test against Mozilla, IE, etc. testling seems to do that (but it's slow and a bit flakey).
Renamed this to reflect that we should switch away from mocha (for a number of reasons: not working in browsers we need to shim is a big one, plus, not working in testling), and then once we're using tape, use testling-ci/browserify to do automatic browser testing.
sorry, not tape but TAP — test anything protocol. testling-ci / browserify should work great with it
That's true - but it also requires ES5 features, which makes it inappropriate to use in a library that targets ES3 browsers as well.
Question: Do we actually want to support ES3 browsers? Their market share is like super low
I'd say so. As a shim, the goal is to patch the oldest possible implementations as much as possible. I think we should support every single browser we can test on, as well as every version of node that's reasonable, and that definitely includes ES3 browsers.
IE 8 won't be out of common usage for a very long time - 23% (according to http://www.netmarketshare.com/report.aspx?qprid=3&qpaf=&qpcustom=Microsoft+Internet+Explorer+8.0&qpcustomb=0 ) is pretty high.
fwiw I'm happy to do the work to convert the tests :-) I've already got a branch in-progress with more than half of them converted anyways. It's not much of a burden to keep the support threshold super low, so we might as well. BDD-style test libs don't add much value imo anyways :-)
FWIW, mocha is working, and it is working in saucelabs. I don't see any reason for changing now for the sake of it.
On the other hand, shifting to test262 is a good idea. But it seems like we already have a test262-to-mocha bridge via @smikes work.
Planned -- not yet delivered. Probably will get some attention this weekend :-)
tape is shit. I suggest using micro-should: https://github.com/paulmillr/micro-should
That's a pretty strong statement without any backing for a package I maintain :-) I use tape on 350+ packages, it works great.
(also, micro-should uses const syntax, which means it can't run on most the engines that actually need es6-shim, so it's a bit of a nonstarter)
strong statement without any backing
Having 300 packages use it and being time-proven is great.
However 21+ dependencies for a test runner is a non-starter. Supply chain attacks are real. Any dependency update will bring potential malware to users.
Micro should is 0-dep 150 loc, third of which is parallel running which should be in an optional separate file.
The need to support ES3 environments is genuine though, micro-should won't help here.
Tape needs to drastically reduce dep count.
The number of deps doesn’t affect the supply chain risk, and the risk for a test runner is virtually zero. More deps is better, and supply chain attacks are a wildly overblown attack vector.
Either way, mocha has far more deps than tape :-) (you also may want to check how much of tape’s graph i personally maintain)
Either way, mocha has far more deps than tape
If you maintain most tape deps personally, mocha indeed seems worse.
supply chain attacks are a wildly overblown attack vector
Different perspective. I would argue the opposite: that it's not as well-known as it should be. I work in infosec. There were lots of rogue NPM packages stealing SSH / cryptocurrency / environment keys. Any package could basically steal it.
and the risk for a test runner is virtually zero.
The risk for a project which handles hundreds of millions of dollars and uses test runner which has rogue deps is huge.
I work in it as well; I was on the board of the OpenSSF last year. There were not, in fact, lots of these incidents - there were tons of proofs of concept, but there were a very small number of actually exploited packages.
If you're concerned with exfiltration, the mitigation is to prevent network access, which has no relationship to the number of deps you have. Separately, this package has nothing to do with handling money (most packages don't, statistically), so I'm not sure how that concern would be relevant here?
Did I never deliver the promised integration? Bummer. The internet remembers too well…
In any case, what is the problem we are solving here?
@smikes in particular, we're stuck on mocha 3, and mocha is on v10, because mocha 4+ dropped support for engines we support; tape latest, however, eternally supports what we do.
If you're concerned with exfiltration, the mitigation is to prevent network access
Preventing network access is not an option in network apps. Also it's barely a mitigation.
It is always possible for the malware to execute a 0day attack and do something terrible to your machine. They could install a silent trojan you won't find. They could infect binaries your machine would be producing. They could gain root access, infect kernel or rewrite firmware on your hardware.
Separately, this package has nothing to do with handling money (most packages don't, statistically), so I'm not sure how that concern would be relevant here?
You don't know which developers would use your software. They could or could not be working with money. It's best to assume they will.
It's also best to assume every package is bad and contains malware. That's why auditability and reducing attack surface is important.
The test runner of this package can't possibly affect consumers, so the only danger would be to developers of this package.
Developers of a package: 1) produce binaries or packed apps for end-users, the malware could be silently injected into binaries 2) can have sensitive info on their machines