ijavascript kernel seems to require the old node v.12.9 (on macOS)

[rudifa]

Running ijskernel in jupyter-lab on a Mac works nicely, but only with a node version <= 12.9.

Now, it would be highly desirable to use the node version 14.15 or later, notably because these support the ES6 modules.

Am I missing something in my installation, or is this a general problem? What could I do to fix it?

My versions:

macOS 10.15.7 (19H2)
jupyter-lab --version : 2.2.6
ijs --version: 5.2.0

FYI, an an attempt to run it with node version 14.15 produces the following diagnostic:

[I 22:32:51.400 LabApp] KernelRestarter: restarting kernel (3/5), new random ports
internal/modules/cjs/loader.js:1122
  return process.dlopen(module, path.toNamespacedPath(filename));
                 ^

Error: The module '/usr/local/lib/node_modules/ijavascript/node_modules/zeromq/build/Release/zmq.node'
was compiled against a different Node.js version using
NODE_MODULE_VERSION 72. This version of Node.js requires
NODE_MODULE_VERSION 83. Please try re-compiling or re-installing
the module (for instance, using `npm rebuild` or `npm install`).
    at Object.Module._extensions..node (internal/modules/cjs/loader.js:1122:18)
    at Module.load (internal/modules/cjs/loader.js:928:32)
    at Function.Module._load (internal/modules/cjs/loader.js:769:14)
    at Module.require (internal/modules/cjs/loader.js:952:19)
    at require (internal/modules/cjs/helpers.js:88:18)
    at Object.<anonymous> (/usr/local/lib/node_modules/ijavascript/node_modules/zeromq/lib/index.js:6:11)
    at Module._compile (internal/modules/cjs/loader.js:1063:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:1092:10)
    at Module.load (internal/modules/cjs/loader.js:928:32)
    at Function.Module._load (internal/modules/cjs/loader.js:769:14)

[n-riesco]

That error means IJavascript was installed using Node.js v12, but it has been launched using Node.js v14. Reinstalling Ijavascript again with Node.js v14 should fix the issue.

[rudifa]

@n-riesco Thank you for the advice, it worked.

I have one (last?) question: does the node process that runs on behalf of the ijskernel read the environment variables?

My experiments below show that the node option --es-module-specifier-resolution=node (passed via NODE_OPTIONS) suffices to run pure ES6 files (using export - import), however the ijskernel + node do not seem to heed it.

Do you have any suggestions here? Thank you, @rudifa

es6-module-in-node14 % ll                                                                                                       
total 48
drwxr-xr-x  13 rudifarkas  staff   416B Nov  1 22:06 .git
drwxr-xr-x   5 rudifarkas  staff   160B Nov  1 22:30 .ipynb_checkpoints
-rw-r--r--   1 rudifarkas  staff   2.0K Nov  1 23:01 Untitled.ipynb
-rw-r--r--   1 rudifarkas  staff   128B Nov  1 20:41 log.js
-rw-r--r--   1 rudifarkas  staff   155B Nov  1 20:42 main.js

# GIVEN ENVVAR

es6-module-in-node14 % echo $NODE_OPTIONS              
--es-module-specifier-resolution=node

# AND 2 FILES

es6-module-in-node14 % cat log.js                                     
// log.js
const log = console.log.bind(console);
const info = console.info.bind(console);

export { info };
export default log;

es6-module-in-node14 % cat main.js                                  
// main.js
import log from './log';
import { info } from './log';

log('log, default export/import works!');
info('info, named export/import works too!');

# THIS WORKS                

es6-module-in-node14 % node main.js           
log, default export/import works!
info, named export/import works too!

# HOWEVER ...

... in a lab cell the import fails

[n-riesco]

@rudifa Sorry I missed your reply. To answer your questions:

• yes, ijskenel opens a real Node.js CLI session (and thus, it's affected by NODE_OPTIONS; although strictly speaking this depends on the frontend and your setup).

• the error you see is the same error you'd see if you try to run import log from '.log' in a Node.js CLI session. For more info, see related issues: #210 #213 #215