dom-testing-library version: 2.6.3react version: n/anode version: 8.4.0npm (or yarn) version: 6.1.0Using any dom-testing-library functionality within a running ember project (ember s) and viewing tests at "/tests";
Attempted to use dom-testing-library along side standard Ember tooling for testing. When assertions failed (elements not found, etc) the debug output is produced.
DTL outputs entire container in the browser window. It appears to be formatted for CLI and is unreadable.
Sorry, I wasn't sure how to pull dom-testing-library into ember-twiddle. Unpkg didn't seem to work.
This makes it almost impossible to debug. This is especially true if using document as your container.
Issue possibly around here with detecting environment (thanks @kentcdodds):
https://github.com/kentcdodds/dom-testing-library/blob/ba44c14f93b4def2b1f8ce0eea8cbaf5c777c735/src/queries.js#L15
I found that in an Ember test
const inNode = typeof module !== 'undefined' && module.exports
will be undefined because, while typeof module is 'object', there's still no module.exports.
I'm not sure what's making DTL think it's in Node or if that is even the true issue.
Maybe we could try to reference variables that we _know_ are Node only. Checking for module is actually just checking whether we're in a CommonJS environment, not Node. So we just need better node detection. Ideas?
process.stdin.isTTY or chalk.enabled for bash color highlight.
The real question asked there is not "inNode", but "canUseBashStyleColorHighlight" or even "shouldReturnAStringWithBashColors", right? And the answer is not just "if in Node, use it", right? So we don't actually need to detect if we're in Node or not, we need to detect where the output is assumed to be printed (i.e. to a terminal that supports colors or to a browser console).
I merged @rossipedia's PR because that makes a lot of sense to me, but I'm re-opening this because @sompylasar is right. It'd be better to check process.stdin.isTTY. Perhaps we could also have an environment variable override. Let's improve this.
:tada: This issue has been resolved in version 2.6.4 :tada:
The release is available on:
npm package (@latest dist-tag)Your semantic-release bot :package::rocket:
Most helpful comment
I merged @rossipedia's PR because that makes a lot of sense to me, but I'm re-opening this because @sompylasar is right. It'd be better to check
process.stdin.isTTY. Perhaps we could also have an environment variable override. Let's improve this.