Bug #6233
openReferenceError: abstractNode is not defined
0%
Description
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/saxon-js@2.6.0.js: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)
Updated by Martin Honnen about 1 year 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 https://www.saxonica.com/saxon-js/documentation2/index.html#!starting/installing-nodejs.
Updated by Norm Tovey-Walsh about 1 year 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.
Updated by Thomas Barnekow about 1 year 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 vercel.com, 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?
Updated by Norm Tovey-Walsh about 1 year 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.
Updated by Thomas Barnekow about 1 year ago
Thanks, Norm. I will produce such an example and share that with you.
Updated by Thomas Barnekow about 1 year ago
Hi Norm, I've created small example in the following repo: https://github.com/ThomasBarnekow/saxonjs-with-nextjs
I appreciate your help.
Updated by Thomas Barnekow about 1 year ago
I have now tried to deploy the project to vercel.com. This leads to a build error along the lines of my original post.
Updated by Thomas Barnekow about 1 year 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).
Updated by Thomas Barnekow about 1 year 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) {
config.externals.push({
"saxon-js": "commonjs saxon-js"
});
}
return config;
},
}
module.exports = nextConfig
This is based on the Next.js documentation (see https://nextjs.org/docs/pages/api-reference/next-config-js/webpack) in conjunction with the webpack documentation on externals (see https://webpack.js.org/configuration/externals/).
Thus, both webpack and esbuild must be configured to "ignore" saxon-js to make it work.
Updated by Thomas Barnekow 11 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.
Updated by Norm Tovey-Walsh 11 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.
Updated by Norm Tovey-Walsh 3 months ago
Apologies for the long delay. I've just tried your saxonjs-with-nextjs
project. I don't see any errors:
$ curl -X POST -H "content-type:application/xml" -d "<doc/>" http://localhost:3000/api/render-content
<!DOCTYPE html>
<html lang="en"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8"><title>SaxonJS Test Document</title></head><body><p>First paragraph.</p><p>Second paragraph.</p></body></html>
Have I done something wrong?
Please register to edit this issue
Also available in: Atom PDF Tracking page