-
Notifications
You must be signed in to change notification settings - Fork 8
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good stuff!
One question - from a design perspective, should the jestRunner
be only in the __test__
folders?
By including it in src
instead of __test__
and exporting it, it means traditionally that we intend for it to be a user-facing API, but given that we'll replace it soon with unmock-jest-runner
and probably won't get a chance to document jestRunner
, I'm not sure we want it to be part of the src
API.
Just a thought, probably a minor detail in the scheme of things as we'll be deleting it soon, but it seems cleaner. Although the disadvantage is that we'd have to copy it to each package that uses it, which having it in one place as you've done solves.
Makes sense @mikesol, although I also think it's something that will soon be replaced (as in the next day or two) so maybe not urgent for the time being. Any thoughts on the build error though? Because that is blocking for merge. |
Agreed that it is bikeshedding. import runner, { IMeeshkanDoneCallback, IRunnerOptions } from "unmock-runner"; I think it should be this instead (haven't tested...): import runner, { IMeeshkanDoneCallback, IRunnerOptions } from "./"; |
- installed mocha - identified the internal mechanism of mocha being treating _any_ error as a showstopper and built that as a foil to jest with a conditional statement. - made a mocha-specific signature that functions almost like the Jest one with minor modifications
Everything's passing now! @mikesol, let me know if I should merge because then I can work on the packages tomorrow. |
Cool! @ksaaskil can also add his review, after which my recommendation would be the following:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Really cool! Also my only comment would be to get rid of imports like ../../unmock-runner/src/jestRunner
and replace those with something like import { jestRunner } from unmock-runner
(if unmock-runner
package exports jestRunner
, I'm not sure if it does :))
import NodeBackend from "../backend"; | ||
const { withCodes } = transform; | ||
import jestRunner from "../../../unmock-runner/src/jestRunner"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, I don't think one should refer to other Lerna packages via "../../../" but with something like import { runner} from "unmock-runner"
. Jest will figure out that unmock-runner
should point to the local package.
@mikesol Will the @ksaaskil That's a good point and I do agree, but it's going to be replaced as soon as we implement the |
No reason to fix it now, it was just a comment :) |
|
@mikesol Yes it does, thank you! Didn't realize that lerna publishes packages automatically. |
Part of #299
unmock-runner
packagejestRunner
function underunmock-runner
to use until we have a properunmock-jest-runner
packageTODO in future PRs:
unmock-jest-runner
(to replacepackages/unmock-runner/src/jestRunner
)unmock-mocha-runner
lint-ts
andlint-ts-fix
commands)@mikesol My build is still failing because it cannot find the
unmock-runner
module. Assuming this is a lerna thing? Any tips for how to resolve would be appreciated.