Expected an identifier and instead saw 'throw' (a reserved word).
In fact, during tests, Internet Explorer 7, at least, breaks due that same error.
Note: I would fork and do a pull request, however english is not my first language, and I can't find a similar word to replace throwwhile keepin its value, if someone finds a similar word, I would gladly do the pull request myself.
.instanceof() suffers from the same problem.
Though maybe not as apparent in the docs as it should be, there is an alias of throws that is mapped to throw. I can also add another alias for instanceof... perhaps instanceOf, capitalizing the the "Of". That should be enough to prevent your tests from emitting linter warnings.
Thoughts on instanceOf?
The IE7 breaks are likely related to #5: my extensive use of Object.defineProperty which is not compatible with pre IE9.
using to. ["throw"] works on IE7 and IE8
Added in alias instanceOf: baf0f63
Will be in next release and will be applied to the should and expect interfaces. Looking through the assert interface now.
@satazor I am assuming you are using the expect interface?
The aliases are in 0.1.7. I'm not too concerned about linter warnings. The need for an expressive TDD language outweighs that.
If this is causing errors, please let me know.
Allright we will those instead to solve the IE7 issues, thank you
@logicalparadox it seems throws is also a reserved word
added Throw, with a capital T, as an alias to `throw` (#7)
meddlesome browsers beware!
add Throw, with a capital T
hope that helps :)
@logicalparadox, I made a lot of changes in order to try to make it work in IE8 but after fixing every .throw and .instanceof i'have blocked in the usage of .defineProperty().
Of course there is no way to support this in IE8. The only solution would be to use .to().be() instead of .to.be.
Guess you won't make the change right?
I've changed to expect.js because of this issue.
IMHO this is a major problem that probably will keep others from using chai.
#5 is something i have yet to get to, which is using a shim to get that past the lack of defineProperty. the problem with shimming that is that is that ie8 half-assed their .defineProperty support for only dom objects.
Anyway, I'll try to move that up on my priority list and have an experimental stubborn browser support branch sometime this week. If you can spare the time, I wouldn't mind a tester.
Nonetheless, thanks for patience and sorry it didn't work out. Leaving this issue open until then.
@logicalparadox Hmm, I suppose expect() could produce a DOM object and then you could use Object.defineProperty to your heart's content... Not sure if you can salvage should though.
Make it even simpler. Try loading es5-shim before chai and see if it works. If it does, can include es5-shim in the browser build (or just the needed parts) in the next release.
I don't have IE as I don't have a windows VM.
Won't work because you can't shim getters on IE8, only value: properties.
So it sounds like the should interface is a no go, but what about the other two? Does the workaround of having expect return a DOM element work? And does the assert interface work?
The workaround for "assert" or "expect" could only work on IE8, but IE7 support is certainly impossible...
@jfirebaugh (sorry for the delay): expect and assert work great in IE9/IE10. In IE8 or below even assert doesn't work, because it depends on the implementation of expect/should :(. It could probably be made to work, by avoiding all getter properties in the assert implementation, but is it worth it?
Closing in favor of a more specific issue.
For the benefit of others that end up here the more specific issue is at #117.
The question is not going to fix it?