Closed danielkcz closed 7 years ago
could you just not load this library in your tests? the sole purpose of this utility is to tell you when the DOM is ready. If there is no DOM, why would you load it?
eg: in your view
if env != 'test'
script(src='domready.js')
Well point of the tests is to test code that goes to the production, right? That mean I would have to modify code just to pass the tests. I don't see it like a good idea :)
Ok, I thought about it and you are partly right. There is no point in running tests that are using DOM when there is no DOM actually present. However domready
should definitely handle correctly if it's running in node environment. As for now, it throws an exception: ReferenceError: document is not defined
. I think it should just stay silent by returning empty function that does nothing.
Btw, if it's meant only for client side, why did you publish in NPM in first place when there is no compatibility with node?
This seems like a super old issue but this is what we do:
We are building a library that is both browser and node compatible. We use browserify to build the browser-compatible distributable.
So we have a local module in `lib/domready.js' with contents:
module.exports = process.nextTick;
In our code we always require ./lib/domready
which defaults to this module for node. Then we configure browserify to replace ./lib/domready
with domready
(the npm module) in our package.json:
"browser": {
"./lib/domready.js": "domready"
},
Thus, regardless of test or production, the process.nextTick wrapper module is used in node, while this domready
module is used in the browser.
+1 to ^
I think this is necessary for tests. For now I am running tests using test'em utility which essentially runs tests in the browser. However when I deploy tests to the CI, my test fails.
It would be nice to incorporate detection of the environment and in case of Node just skip all the document stuff and just use
process.nextTick
to call attached callbacks.