<ELLIOTTCABLE>
lol the test-support file for the project dives head-first into mocha, swirls everything around and fucks it all up, and then falls back out
<purr>
lolicode
<ELLIOTTCABLE>
purr: ... no
<ELLIOTTCABLE>
now that I've done all that work, I really should extract it to a module.
jonathanzuniga has quit [Quit: Connection closed for inactivity]
<ELLIOTTCABLE>
yes, that entire file is littered with type-annotations, how did you miss that :P
<ELLIOTTCABLE>
jfhbrook: is there something else it's supposed to end in?
<jfhbrook>
idk, .flowtype ?
<ELLIOTTCABLE>
lol.
<purr>
lolol
<ELLIOTTCABLE>
it's not a programming language, it's a static analyzer
<jfhbrook>
.notjs ?
<ELLIOTTCABLE>
that stuff might as well be in /* comments */
<ELLIOTTCABLE>
in fact, it works just as well if you put them in /* comments */
<jfhbrook>
yessch
<ELLIOTTCABLE>
but if you're already transpiling with babel ... might as well take the type-annotations out of the comments and drop them in raw.
<jfhbrook>
yeah I guess
<ELLIOTTCABLE>
you just wait until they open up Babylon and my .js files have no () or {} 'cuz semantic whitespace
<ELLIOTTCABLE>
*then* you can moan :P
<jfhbrook>
I didn't know mocha had exports
<ELLIOTTCABLE>
huh?
<ELLIOTTCABLE>
exports?
<jfhbrook>
import { Suite, Test, Hook } from 'mocha'
<ELLIOTTCABLE>
ah
<jfhbrook>
never thought to require('mocha')
<ELLIOTTCABLE>
yeah there's a pretty clean API
<ELLIOTTCABLE>
although everything in that file *mangles* it
<ELLIOTTCABLE>
I looked into creating a new Hook family and shit, but unfortunately, rn, their API is tightly-coupled to the idea of hooks being a property of *suites*
<jfhbrook>
yeah, I'm trying to figure out why
<jfhbrook>
because mocha already has before and after hooks
* ELLIOTTCABLE
laughs
<jfhbrook>
maybe not as fine-grained as you need?
<ELLIOTTCABLE>
yes, these are *specific to the test in question*.
<jfhbrook>
oh jesus
<ELLIOTTCABLE>
Yep
<jfhbrook>
so either use more describes or just do more shit in the it block
<ELLIOTTCABLE>
this is basically re-implementing half of Hook and Runnable, with a wrapper-function that replaces the test-body
<ELLIOTTCABLE>
see, yeah, but this was all support for the very *last* things in the file:
<ELLIOTTCABLE>
describe(
<ELLIOTTCABLE>
setupEach('git init')
<ELLIOTTCABLE>
it( ()=> does stuff )
<ELLIOTTCABLE>
.setup('touch foo', 'git add foo')
<ELLIOTTCABLE>
)
<jfhbrook>
seriously, I'd just throw that abstraction out the window because I don't really care XD
<jfhbrook>
like I see what you're doing
<ELLIOTTCABLE>
while running an arbitrary chunk of JavaScript *outside* of the test-body isn't *all* that useful (wrap it in a function, call that function at the start of the body … or whatever), this is all set up to do *much* more than that
<jfhbrook>
but that's a lot of effort
<ELLIOTTCABLE>
yeah there's reasons:
<ELLIOTTCABLE>
1. failures aren't failures *of the test*, they're failures of the setup, and need to be handled differently;
<ELLIOTTCABLE>
and 2. there's a bunch of working-directory-changing shit that needs to happen.
<ELLIOTTCABLE>
that's the primary purpose of basically that entire file: automatically creating a working-directory specific to every test that needs to *have* a working directory;
<ELLIOTTCABLE>
and then allowing me to cache that whole pile of shit across machines
<jfhbrook>
heh
<ELLIOTTCABLE>
(basically, once the test-suite, however big it is, laboriously generates five hundred git repos ... I can zip up the entire working-directory, which has a sub-dir for each test, and ship it off to bintray or something.)
<ELLIOTTCABLE>
now that i've done all this work I'll probably abstract it into a module :P
<jfhbrook>
yeah I mean an extension module could be chill
<ELLIOTTCABLE>
most of the abstraction already ended up being done, it's probably like an hours' clean-up to modularize it lawl
<jfhbrook>
you already did the work, I'm sure at least parts of this would be useful
<ELLIOTTCABLE>
I just ... don't want to do that unless it looks like I CAN'T work within the bounds of mocha
<ELLIOTTCABLE>
because I don't like how this approach completely ignores How Mocha Works.
<jfhbrook>
maybe make it slightly more general though?
<ELLIOTTCABLE>
yeah.
<jfhbrook>
ELLIOTTCABLE, Mocha Works == Not Very Well
<ELLIOTTCABLE>
*if* I split this out, I'd have three TODOs:
<jfhbrook>
I always thought isaac's tap module was the best one for node
<ELLIOTTCABLE>
1. if at all possible, turn the hooks into true mocha Hooks (and thus get mocha's error-handling and prettiness on failure),
<jfhbrook>
though I'm really used to chai asserts now though
<ELLIOTTCABLE>
2. make it a little more sync-friendly (should be *possible* to run commands asynchronously … right now this entire mess FORCES you to run tests asynchronously)
<ELLIOTTCABLE>
yeah I love TAP
<ELLIOTTCABLE>
I just don't like *writing* in TAP
<ELLIOTTCABLE>
but I also don't like *writing* in JavaScript.
<jfhbrook>
shockingly, I still like javascript
<ELLIOTTCABLE>
so meh mocha -> tap, when you've already lost semantic whitespace, is probably not a big loss.
<jfhbrook>
I find it comfortable
<ELLIOTTCABLE>
I have to copy-paste so much
<jfhbrook>
I'm like finally getting a little into es6 too, just using features as I find them
<jfhbrook>
no transpiling though
<ELLIOTTCABLE>
because *fuck* typing `describe("this", function(goddamn){ // shit` over and fucking over
<jfhbrook>
it turns out the pace of features in the LTS releases is a good learning speed for me
<ELLIOTTCABLE>
jfhbrook: ahahha
<ELLIOTTCABLE>
cute
<jfhbrook>
yeah well
<ELLIOTTCABLE>
I'm the opposite: been avoiding *all* of them, for years, while working on paws; and I just dived into *them all at once* on this side-project
<ELLIOTTCABLE>
fun facts:
<ELLIOTTCABLE>
I spent 1h14m exploring the tooling choices I'd use for this,
<jfhbrook>
yeah maybe in 18 months I'll learn generators
<ELLIOTTCABLE>
7h43m installing, configuring, failing at, fixing, and learning, all that tooling (basically: learning ES6.),
<ELLIOTTCABLE>
7h20m writing the low-level parts of that support.js (directoryExists, enableBefores, beforeThis, needsDir)
<ELLIOTTCABLE>
and then 1h34m writing setup() and setupEach() and cleaning up the tests for all of the above.
<ELLIOTTCABLE>
I love time-tracking (ˇ⊖ˇ)
<ELLIOTTCABLE>
tbh,
<ELLIOTTCABLE>
this is basically the first time I've used promises :x
<ELLIOTTCABLE>
jfhbrook: that's how behind I was >,>
<jfhbrook>
heh
<jfhbrook>
yeah, I only got into promises this last summer
<ELLIOTTCABLE>
I was vaguely aware of them, and could replace `, function(){ ... })` with `).then(function(){ ... })` where necessary
<jfhbrook>
I get why Systems People hate them
<ELLIOTTCABLE>
but that was like the extent of my desire to touch them
<ELLIOTTCABLE>
this project is the first time I *forced myself* to use them everywhere I possibly could
<ELLIOTTCABLE>
and now I *kinda* get the appeal, but like ... I still think we're replacing callbacks too willy-nilly.
<jfhbrook>
but I've been using them for relatively safe processes that merely needed to return "lol failed" to the user when something failed
<purr>
lolol
<ELLIOTTCABLE>
lol failed
<ELLIOTTCABLE>
fuckit
<ELLIOTTCABLE>
adding a ‘lol’ mode to Paws
<jfhbrook>
like Promise.resolve(context).then(doTheThing).then(doTheOtherThing).catch(giveHapiTheError).then(giveHapiTheResponse)
<jfhbrook>
heh
<ELLIOTTCABLE>
if you invoke Paws.js as lolpaws instead of just paws, all errors are replaced with console.log('lol.')
<jfhbrook>
promises have a few cool tricks up their sleeves though
<ELLIOTTCABLE>
and every possible kind of catch thingie will be invoked to make sure that execution never, ever gives up
<jfhbrook>
it's cool that you can map and reduce over promises, and that you can memoize values inside promises
<ELLIOTTCABLE>
and it just keeps doing everything, no matter how fucked-up the state gets, spitting out more and more "lol."'s as the system becomes more and more internally corrupt and inconsistent
<jfhbrook>
hahaha
<jfhbrook>
like some kinda weird interpreted seizure
<ELLIOTTCABLE>
yesssss
<ELLIOTTCABLE>
the “I want to see what *would have* happened if this runtime-check had been omitted” mode
<ELLIOTTCABLE>
dangerous af too
<ELLIOTTCABLE>
might have to include some sort of in-process sandboxing
<ELLIOTTCABLE>
it'd have to use a specialized build of V8, too; disabling all the error-checks in *there*
<ELLIOTTCABLE>
(instead of 'lol.' those would print 'LOL FAULT')
<purr>
<sephr> yeah I had to change my opinion so I could disagree with you
alexgordon has joined #elliottcable
alexgordon has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
alexgordon has joined #elliottcable
alexgordon has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
alexgordon has joined #elliottcable
<incomprehensibly>
ELLIOTTCABLE: I used some nice deferreds at work
<ELLIOTTCABLE>
incomprehensibly: what is difference from promise
<incomprehensibly>
I think they are promises but might be different
<jaawerth>
it's just the old way to make promises, without the promise constructor
<incomprehensibly>
ah
<ljharb>
ELLIOTTCABLE: the difference is that a Deferred exposes "resolve" and "reject"
<ljharb>
that's the only difference
<jaawerth>
var deferred = Q.defer(); // do stuff, asyncronously call deferred.resolve(value); return deferred.promise;
<ljharb>
and it's considered an antipattern to expose those to callers.
<ljharb>
jQuery and Q both have deferreds
<jaawerth>
I hate them
<jaawerth>
(deferreds, that is)
<ljharb>
and you can make a Deferred with a Promise with `function Deferred() { var resolve, reject, p = new Promise((y, n) => { resolve = y; reject = n; }); return Object.assign(p, { resolve, reject }); {`
<ljharb>
oops, } not { on the end there
<jaawerth>
yeah. once in a while I do that if I need to expose manual triggers for resolve/reject, but it's a rare usecase
alexgordon has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<jaawerth>
So, I've been browsing input validation libs today for something that'll save me some boilerplate for validating complex object inputs
<jaawerth>
I admittedly only looked at this one because I was amused by the juvenile name and tagline but it looks surprisingly decent https://www.npmjs.com/package/uranus
alexgordon has joined #elliottcable
<purr>
<sephr> it was my sexy name
jonathanzuniga has joined #elliottcable
janey has joined #elliottcable
janey has quit [Changing host]
janey has joined #elliottcable
jane has quit [Ping timeout: 255 seconds]
audy has quit [Ping timeout: 255 seconds]
janey is now known as jane
audy has joined #elliottcable
silentbicycle has quit [Ping timeout: 265 seconds]
silentbicycle has joined #elliottcable
<purr>
<jeannicolas> you guys have a way of grabing a programming language and making it suck its own wiener!
<pikajude>
that's disgusting
<jaawerth>
yeah where are these bot quotes coming from anyway? heh
<jaawerth>
presumably things people said in this channel, must be some command to make the bot remember it
eligrey has joined #elliottcable
meowrobot_ is now known as meowrobot
alexgordon has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
alexgordon has joined #elliottcable
alexgordon has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]