This is Node.js v10.16.0 on Windows 10 64-bit. We also see this on Node.js v10.16.2 on Linux 64-bit.
This is a really puzzling and intermittent error and I must apologise but it's been very difficult to come up with consistent steps to reproduce it. I feel as if the problem may be environmental but there are aspects of how bytenode works which I do not understand so I'm not sure what kind of environmental issue could be causing this, which is why I'm reaching out for help. Here's the minimal scenario I've managed to concoct:
src/main.js:
console.log('hello world')
build/build.js (this consumes src/main.js and outputs dist/main.jsc):
const bytenode = require('bytenode')
const fsExtra = require('fs-extra')
const tmp = require('tmp')
fsExtra.removeSync('./dist')
fsExtra.ensureDirSync('./dist')
const source = fsExtra.readFileSync('./src/main.js')
const tmpFile = tmp.fileSync()
fsExtra.writeFileSync(tmpFile.name, source)
bytenode.compileFile({
filename: tmpFile.name,
compileAsModule: true,
output: './dist/main.jsc'
})
dist/main.jsc is about 1kB of bytecode, of course, and I can't attach it, but here's the Base64 for it if that's any use:
tQPewIr01PReAAAA/wMAAOyrzzQGAAAAAAAAAGgDAAC6UcawNe4pcAAAAIAgAACAwAQAgAAAAIAAAACAAAAAgAIskwIkFsjAAAAAAAgAAAACDIzAAAAAAAEAAAACLJMCLPDAAAAAABcAAAACFIzAAAAAAAMAAAACEJHCutOeVQAAAAAAAAAABwAAAGNvbnNvbGUAAhCRwobZQrcAAAAAAAAAAAMAAABsb2cAAAAAAAIUkcP+HxH6AAAAAAAAAAALAAAAaGVsbG8gd29ybGQAAAAAAAIIi8AAAAAAAAAAAAIQi8IAAAAACgAAAAEWAmgLEBUADCoAAAAAAADFGAAAADAAAAAAAAAAAEACAAAAoBMAACb6KPoBAib7EgIm+Vf7+vkEDaQAAAAAAAAAAkSSxAAAAAAPAAAAAAAAAMFdAAAAAAAABQAAAAAAAAAAAAAAAAAAAAAAAAACEJHCLvpbsAAAAAAAAAAABwAAAGV4cG9ydHMAAhCRwp7Ws14AAAAAAAAAAAcAAAByZXF1aXJlAAIQkcLSPVIMAAAAAAAAAAAGAAAAbW9kdWxlAAACFJHDlgXFAgAAAAAAAAAACgAAAF9fZmlsZW5hbWUAAAAAAAACFJHDUlynEgAAAAAAAAAACQAAAF9fZGlybmFtZQAAAAAAAADAAAAAAAAAAACJwAAAAAD/////hMEAAAAACgAAAAAAAABcAAAAAggWuMAGAAAABhRAAAJEFs0HFwACGJHEIpY3ZQAAAAAAAAAAFwAAAGV2YWxtYWNoaW5lLjxhbm9ueW1vdXM+AMEAAAAAAAAAAAAAAAAAAAAAhODAAAAAAAIAAACEwAAAAACHAAAAhMAAAAAAAAAAAAEQFi0BwAAAAAACAAAAfgoAfgpcwAAAAAACAAAAhOCewAAAAAAEAAAAicMBAAAABQAAAAUAAAAKAAAAKAAAAFwAAAABAAAAAAgAAAIIi8AAAAAAAAAAAAIMi8EAAAAABwAAAAECAgAMugEAwwgAAAAIAAAAAAAAAABAAgAAAKB8AAAAJvukAAAAAAAAAjCSxQAAAAAKAAAAAAAAAEMMAAAAAAAAAAAAAAAAAAABAAAAAAAAAAAAAAAAAAAAAAAAABblA4nCAAAAAP////8AAAAAAAAAAAAAAABeAAAAAgjxwAEAAAASAAAACrkBwAAAAAAEAAAAicMAAAAAAAAAAAAAAAAKAAAAAgAAAF4AAAD/////AAgAABwvLy8vLy8v
index.js (this serves as the entry point):
require('bytenode')
module.exports = require('./dist/main.jsc')
When I run index.js, I get
hello world
Process finished with exit code 0
When I debug index.js (my debugger in this case is WebStorm 2019.2), I get
Debugger listening on ws://127.0.0.1:59811/0c14ba72-bbe5-476b-9ba7-979b3b9a6b03
For help, see: https://nodejs.org/en/docs/inspector
Debugger attached.
C:\Users\...\node_modules\bytenode\index.js:216
return compiledWrapper.apply(module.exports, args);
^
TypeError: compiledWrapper.apply is not a function
at Object.Module._extensions.(anonymous function) [as .jsc] (C:\Users\...\node_modules\bytenode\index.js:216:26)
at Module.load (internal/modules/cjs/loader.js:653:32)
at tryModuleLoad (internal/modules/cjs/loader.js:593:12)
at Function.Module._load (internal/modules/cjs/loader.js:585:3)
at Module.require (internal/modules/cjs/loader.js:690:17)
at require (internal/modules/cjs/helpers.js:25:18)
at Object.<anonymous> (C:\Users\...\index.js:2:18)
at Module._compile (internal/modules/cjs/loader.js:776:30)
at Object.Module._extensions..js (internal/modules/cjs/loader.js:787:10)
at Module.load (internal/modules/cjs/loader.js:653:32)
Waiting for the debugger to disconnect...
Process finished with exit code 1
I also see this problem when not debugging, in some scenarios where the bytenoded source is much larger. In this case I find that trying to load the module interactively, e.g.
node
> require('my-module')
TypeError: compiledWrapper.apply is not a function
> require('my-module')
TypeError: compiledWrapper.apply is not a function
causes the compiledWrapper error to repeat on each attempt... but simply exiting the interactive session and running node again can cause the problem to go away semi-permanently.
Closer inspection of Module._extensions[.jsc] indicates that under normal circumstances, the value returned from compiledWrapper = script.runInThisContext(...) is a function, whose string representation is 91 copies of U+200B ZERO WIDTH SPACE in a row. But in the failure case, compiledWrapper is simply a 92-character string consisting of U+200B ZERO WIDTH SPACEs. In both cases length = readSourceHash(bytecodeBuffer) returned 94. A string has no apply method on it, hence the error.
What could be causing this?
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4