Saxon » SaxonJS

I'll definitely investigate creating an NPM package for the browser version.

Regarding modules, the distribution is compiled with the Closure compiler and my investigations didn't turn up any leads for how to get the Closure compiler to produce ESM modules (see bug #4655 on which you've already commented).

I'd be happy to hear about ways that we could make the distribution easier to use.

Hi Norm, that's great to hear. You should be able to publish both the node.js and browser version in the same npm package.

I'm coming back to this again. (I know it's been ages.)

I can bundle the browser version, that I've tested. Then you could install it with npm and refer to the source with:

<script src="node_modules/saxon-js/saxonjs3.rt.js"></script>

But is that really sufficient?

This would be an improvement for dependency management, but ideally, the browser version would be exported from the package.json so you can import it, also:

import SaxonJS from 'saxon-js';

If both browser and node exports are provided, the bundler will import the correct one based on the context. In the browser, you'd then reference the local SaxonJS object rather than global.SaxonJS.

In what context do you write that import statement? I feel like there's more going on here than I understand. I tend to think of using SaxonJS (or any other JS thing) in the browser as a thing you do with <script> tags, but that's not what's going on here.

The Javascript packaging world is a mess. :)

You'd write the import statement in the context of a codebase where SaxonJS was npm-installed. node.js module resolution would then resolve the actual file from node_modules. Then, as a developer who wanted to run your application in node.js, it would "just work."

If you wanted to bundle your application to run in the browser, your chosen bundler would resolve the browser version from package.json, and use that instead. The bundler would produce a compiled packaged optimized for the web, including both SaxonJS as well as other utilized libraries.

Import statements may also be used in the browser, to import a remote ESM - https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import

For library development, Rollup is a common choice for bundling ESM modules. Your choice would depend a bit on what module format the code is written with (ESM, CommonJS, AMD, others...). I'd imagine, to cover your bases, you'd want the compiler to output both ESM and CommonJS bundles, as well as something compatible with the current script tag approach.

Thanks. That's not a million miles from what I was imagining. I'm still need to find or figure out how to construct a test case that I can code against.