Check/improve browser support

[tdegrunt]

• Add browser based tests
• Add bower package support

[awwright]

With browserify it seems to work out of the box, though it may need an ES5 shim on some web browsers.

(I spent a ridiculous amount of time bugfixing browserify though, ugh.)

[tdegrunt]

Yeah, I started down that path, found it buggy too.

[awwright]

Update: Browserify seems to work pretty well; idk if this is the preferred way, but I just have a simple little script saying window.JSONSchema=require('jsonschema'); and I compile that, and presto!

Now, is there a preferred way to publish a build like this, that's easier for people to consume?

http://wzrd.in/standalone/jsonschema@latest seems to work pretty well; just pull in that script and it creates a jsonschema variable you can call just like require('jsonschema'). Nifty!

[tdegrunt]

Oh wow, that's awesome!

I suggest we just use Bower (http://bower.io) for this. Have never created a package for Bower though, just using them at the moment. We would need to add a bower.json, which points to the built script, which we would then need to commit (in a separate folder?).

[laurelnaiad]

I've been using jsonschema browserified. Two things would make it "better".

1. A whole bunch of replacement code gets compiled in due to use of "url" module in node. I think there is room for a much lighter library or custom code to significantly cut the size of the browserified file.

Here is an angular module that wraps and extends jsonschema:

• https://github.com/marklogic/marklogic-samplestack/blob/master/browser/src/_marklogic/services/data/_jsonschema.browserify.js -- exposes jsonschema as a require.js AMD module
• https://github.com/marklogic/marklogic-samplestack/blob/master/browser/src/_marklogic/services/data/mlSchema.js (angularizes and extends it)

2. There is use of Error.captureStackTrace in jsonschema which isn't cross-browser-safe (I think it's V8-only), so it would be best to find another way to report stack traces (we use https://github.com/stacktracejs/stacktrace.js but I see as I write this that I forgot to tweak the Error prototype in order to use this library to patch it.

[awwright]

@laurelnaiad Yeah, I noticed that too.

I maintain my own URI/IRI library, idk if it's lighter weight by comparison, but I venture to guess much of the entire thing is necessary because the bulk of the code is URI Reference resolution.

Hmm, I think I added the Error.captureStackTrace call, though I don't remember anything about it. I think the point isn't so much about capturing a stack trace, as it is extending the builtin Error object. If there's a better way to do that cross-platform then let's do that.

[laurelnaiad]

Re captureStackTrace... right now on FF it's an unhandled error when that line of code is hit, so the original error gets 100% lost unless you've mokeypatched. Shows up when you have invalid and/or malformed schema, making FF a bad place to try to develop your schema. :)

[awwright]

Should we just skip that line if the function doesn't exist? I don't see what use it's even serving.

[laurelnaiad]

I think it's part of one of the millions of ways people derive from Error. In this case, attempting to maintain the stack trace of the original error. I think that the solution should ensure that the stack traces don't go away, so just skipping that line may not do the trick due to the way SchemaError is implemented. In other words, there's probably another way to accomplish the (a) maintaining the stack trace and (b) customized Error derivative) both while having it work in vanilla javascript.

[hadesara]

Any update on this? I would love to see this browserified (cross-browser).

[awwright]

@hadesara I use 'jsonschema' browserified. If there's any problems for you then open a bug report and I'd be happy to take a look at it.

[awwright]

Loading https://bundle.run/jsonschema@1.2.11 in a script tag appears to work without any modifications. It creates a jsonschema global variable.