Bug #6233


ReferenceError: abstractNode is not defined

Added by Thomas Barnekow 9 months ago. Updated 7 months ago.

Start date:
Due date:
% Done:


Estimated time:
Applies to JS Branch:
Fix Committed on JS Branch:
Fixed in JS Release:
SEF Generated with:
Contact person:
Additional contact persons:


I am trying to use SaxonJS 2.6.0 within a Next.js 13 project. I am using code that works on the Node.js runtime in Azure Functions. However, the same code leads to the following exception in Next.js:

⨯ node_modules/.pnpm/saxon-js@2.6.0/node_modules/saxon-js/SaxonJS2N.js (4640:147) @ abstractNode ⨯ ReferenceError: abstractNode is not defined at eval (webpack-internal:///(rsc)/./node_modules/.pnpm/saxon-js@2.6.0/node_modules/saxon-js/SaxonJS2N.js:277426:14) at (rsc)/./node_modules/.pnpm/saxon-js@2.6.0/node_modules/saxon-js/SaxonJS2N.js (/Users/thomas/Source/Repos/platforms-starter-kit/.next/server/vendor-chunks/:20:1) at webpack_require (/Users/thomas/Source/Repos/platforms-starter-kit/.next/server/webpack-runtime.js:33:43) at eval (webpack-internal:///(rsc)/./app/api/render-service-levels/route.ts:5:66)

Actions #1

Updated by Martin Honnen 9 months ago

I don't know anything about Next.js. Which Node.js version does it use? SaxonJS 2.6 requires Node.js 18 or higher!starting/installing-nodejs.

Actions #2

Updated by Norm Tovey-Walsh 9 months ago

The reference to webpack_require suggests that Next.js is built on top of some specific framework related to webpack. I've tried once or twice to understand webpack and work out if/how SaxonJS could be made to work with it, but I've never been wholly successful.

It's possible that SaxonJS is simply not compatible with Next.js.

Actions #3

Updated by Thomas Barnekow 9 months ago

So far, I have only run this on my local machine, which has Node v18.15.0 installed. Next.js v13 itself requires at least Node v16.14.0. When hosting the Next.js app on, the Node.js version can be configured per project. In my case, the configured Node.js version is 18.x. Thus, I would assume that the Node.js version is not the root cause.

What I see in the exception message (see above) is that webpack plays a role. Could that play a role?

Actions #4

Updated by Norm Tovey-Walsh 9 months ago

Yes, webpack is very likely (part of) the problem. If it's possible to construct a small example that we could use to reproduce the issue, I'm happy to take a look.

Actions #5

Updated by Thomas Barnekow 9 months ago

Thanks, Norm. I will produce such an example and share that with you.

Actions #6

Updated by Thomas Barnekow 9 months ago

Hi Norm, I've created small example in the following repo:

I appreciate your help.

Actions #7

Updated by Thomas Barnekow 9 months ago

I have now tried to deploy the project to This leads to a build error along the lines of my original post.

Actions #8

Updated by Thomas Barnekow 9 months ago

Based on the assumption that SaxonJS might not work with webpack at all, I've now tested SaxonJS using the Serverless Framework. That framework allows me to create serverless functions on Node.js. However, when using TypeScript rather than plain JavaScript, you'd use esbuild to transpile and bundle the TypeScript code. That then leads to the exact same issue as with webpack. Thus, it seems that any bundling leads to the same issue (hypothesis).

I've then created a plain-vanilla JavaScript project to see whether that works. It does!

To avoid having to create and deploy separate APIs, I then tried to find out whether esbuild lets me "ignore" the saxon-js library. The good news is that this is indeed possible. In the serverless.yml file, I had to include the following to make that happen:

custom: esbuild: external: - "saxon-js" - "xslt3"

With that setting, I can now use SaxonJS in the TypeScript project that is otherwise transpiled and bundled by esbuild.

One thing to check would now be whether webpack can also be configured to do behave like esbuild regarding the saxon-js library.

Overall, SaxonJS is problematic in modern JavaScript (ESM modules) and TypeScript projects. The question is whether you have any plans to change that with a next release of SaxonJS (which is otherwise a great processor, albeit a bit hard to use in certain scenarios).

Actions #9

Updated by Thomas Barnekow 9 months ago

I've now also made SaxonJS work with Next.js and webpack, essentially telling webpack to ignore the saxon-js library in next.config.js:

/** @type {import('next').NextConfig} */
const nextConfig = {
  webpack: (config, { isServer }) => {
    if (isServer) {
        "saxon-js": "commonjs saxon-js"

    return config;

module.exports = nextConfig

This is based on the Next.js documentation (see in conjunction with the webpack documentation on externals (see

Thus, both webpack and esbuild must be configured to "ignore" saxon-js to make it work.

Actions #10

Updated by Thomas Barnekow 7 months ago

Hi Norm, just wanted to ask whether there are any further activities on your end regarding this issue.

As noted in my previous message, I solved the issue for my use case. Thus, unless you are planning to introduce some fix, you could close this and publish the solution.

Actions #11

Updated by Norm Tovey-Walsh 7 months ago

Not yet. We're turning our attention to what needs to be in the next SaxonJS release now and I'll make sure this is given adequate review. Apologies for the delay.

Please register to edit this issue

Also available in: Atom PDF Tracking page