Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jest interferes with file reading in Fengari Lua runtime #10368

Closed
cableray opened this issue Aug 6, 2020 · 4 comments
Closed

Jest interferes with file reading in Fengari Lua runtime #10368

cableray opened this issue Aug 6, 2020 · 4 comments

Comments

@cableray
Copy link

cableray commented Aug 6, 2020

🐛 Bug Report

I wrote some tests around node code that uses the Fengari Lua runtime to run Lua code in JS. This works well, except when trying to load files in the Lua runtime. Outside of Jest (running the tests in the node jasmine runner) this code works. But inside jest, non-empty files fail to load (even if they only have whitespace) with Lua not even reporting an error message (like it usually does). My suspicion is that this has something to do with how jest isolates the global environment, maybe even isolating file handles or file buffers? While debugging the issue I noticed some file buffers did not reflect my file's contents. However, I'm not familiar enough with what magic Jest does to figure it out on my own.

I also created an issue with Fengari: fengari-lua/fengari#182

To Reproduce

Steps to reproduce the behavior:

Try loading a lua file through Fengari in a Jest test:

global.WEB = false // not sure if this is needed
const { lua, lauxlib, lualib, to_luastring: toLuaString } = require('fengari')
const interop = require('fengari-interop')

test('Lua can load a file', () => {
    const L = lauxlib.luaL_newstate()
    lualib.luaL_openlibs(L)
    lauxlib.luaL_requiref(L, toLuaString('js'), interop.luaopen_js, 1)
    lua.lua_pop(L, 1) // remove lib from stack

  const errorCode = lauxlib.luaL_dofile(L, 'test-load.lua')
  if (errorCode) {
    throw Error(`${errorCode}: ${lua.lua_tojsstring(L, -1)}`)
  }
  expect(interop.tojs(L, -1)).toBe('file loaded')
})

file ./test-load.lua

return 'file loaded'

The result I get back is error code 2, with a null message

Expected behavior

Test passes: The result of the Lua script is returned to the jest test. (As it is with jasmine).

envinfo

  System:
    OS: macOS 10.15.5
    CPU: (8) x64 Intel(R) Core(TM) i7-4870HQ CPU @ 2.50GHz
  Binaries:
    Node: 13.11.0 - /usr/local/bin/node
    Yarn: 1.22.4 - /usr/local/bin/yarn
    npm: 6.13.7 - /usr/local/bin/npm
  npmPackages:
    jest: ^24.9.0 => 24.9.0 
    fengari: 0.1.4
    fengari-interop: 0.1.2

jest.config.js:

module.exports = {
  testEnvironment: 'node',
  // Exit the test suite immediately upon the first failing test suite
  bail: true,
  // Each individual test should be reported during the run
  verbose: true,
  setupFilesAfterEnv: ['jest-extended'],
  collectCoverageFrom: ['app/**/*.{js,jsx}', '!**/node_modules/**'],
  coverageReporters: ['html', 'text', 'cobertura'],
  testPathIgnorePatterns: ['/node_modules/'],
  testMatch: ['<rootDir>/test/**/?(*.)+(spec|test).js?(x)']
}
@fmhdp
Copy link

fmhdp commented Apr 29, 2021

TL;DR:
buff instanceof Uint8Array where buff is an instance of a Node.js Buffer returns true when run under Node directly but false when run under Jest and a type check blows up.
Setting the tst environment solves this.

I am experiencing probably the same problem with jest.
My test case might be even simpler, though, since I stumbled across the problem trying to execute a "require" statement in a Lua script. If I execute the same script without jest, the require works and luaunit, the library I tried to require, is loaded and works.

Jest versions:
"jest": "26.6.3", "ts-jest": "26.5.5",
Jest config:
module.exports = { preset: "ts-jest" };

I tried to debug this problem a bit and the problem starts to appear at the return code of luaD_protectedparser here: https://github.com/fengari-lua/fengari/blob/dfdd62974fe6044f2c947a17be206c83edcd1f1a/src/ldo.js#L725.
It should return 0 (LUA_OK), but returns a non-zero value (2 for me).

Digging a bit deeper the difference between running under Jest and running directly under node is the result of a type check here: https://github.com/fengari-lua/fengari/blob/dfdd62974fe6044f2c947a17be206c83edcd1f1a/src/lzio.js#L53

The context is that the ZIO class (just above in the code) is some buffered reader. If it hits the end of its internal buffer it tries to fill it by calling luaZ_fill. This function calls the reader in the ZIO, which should produce the next buffered piece or return null to indicate EOF.
After the buffer has been return there's a type check made for whether the returned buffer is an Uint8Array. This check succeeds under Node but fails under Jest. In both cases VS Code's debug console tells me the actual type is Buffer.

Sure enough if you google for the problem, you end up at #4422
The first suggestion there is to set the jest environment to node, which failed for the guy trying it back then.
For me it worked, simply putting
`/**

  • @jest-environment node
    */`
    at the top of the file makes things work now.

@github-actions
Copy link

This issue is stale because it has been open for 1 year with no activity. Remove stale label or comment or this will be closed in 30 days.

@github-actions github-actions bot added the Stale label Feb 17, 2023
@github-actions
Copy link

This issue was closed because it has been stalled for 30 days with no activity. Please open a new issue if the issue is still relevant, linking to this one.

@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale Mar 19, 2023
@github-actions
Copy link

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
Please note this issue tracker is not a help forum. We recommend using StackOverflow or our discord channel for questions.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Apr 20, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants