Is there any way to use "require" directly not only "jsreport.assets.require"

admin

The jsreport.assets.require should be used primarily to require asset entities. In your case, you should use the normal require.

const test3 = require('./test3.js'); **// It works if I require it like this.**

This looks correct, the ./test3.js is a relative path to the /server/test2.js

Note it seems like we have a bug that is reporting the wrong module name when require fails on nested dependency, I am looking on it so far. I will come back...

Also, note that the modules are kept in the nodejs require cache. So better to always restart jsreport when troubleshooting this.

JoeyLi-1

"The jsreport.assets.require should be used primarily to require asset entities. In your case, you should use the normal require."

Yep, you are right. I can only make it work by "jsreport.assets.require" at the very beginning of upgrade. And that might because I did not use "'allowModules': "*"" at the very beginning. It complains about "can not find module" or "does not have permission..." every time. Previously, I use relative path for each script in allowModules array. something like: "./server/test1.js" etc.

Now, I had reverted all the code and just add "'allowModules': "*"" . It will not complain about require issue anymore. Just hung there, I am going to trouble shooting the new issue.

Useful tips while upgrade:

Do not use "jsreport.assets.require". Otherwise you will encounter lots of wired issue about "require".
Relative path shall be used for all your custom scripts.
If require(./test) does not work. Try require('./test.js'). They should be same thing, but I dont know.
Use "'allowModules': "*"" in your jsreport config file.

Thank you! @jan_blaha

admin

The allowModules config is duplicated when you use trustUserCode.
https://jsreport.net/learn/configuration#trusting-users-code

JoeyLi-1

"The allowModules config is duplicated when you use trustUserCode"
-- Yep, I saw that mentioned in upgrade documentation. Upgrade job contains too many errors and I have no idea which one take effect. So, I just accept both in my config file.

I finally locate the error. It is because failed to require a js file. That file is compiled from a typescript file. We had build a demo project to reproduce the issue. https://github.com/Davidliu11/jsreport-test

data\scripts\test\content.js -> require('./data/scripts/test1.js');
test1.js -> require('../../dist/application') Then error occurred: "'uncaughtException: Error when evaluating custom script /scripts/test"

I had required same file in server.js and it works fine.
You can either clone or download the demo and just npm install and npm start. You will see the error.

Our Node version v18.16.0.

Why same js file could be required by normal js file but failed in JSreport helper file? Please do help me. Thank you!

@jan_blaha

JoeyLi-1

Hi Jan,

I found the root cause. Seems jsreport does not support "require('..');" in new version.
If I add "console.log('error: ', e);" at node_modules@jsreport\jsreport-core\lib\worker\sandbox\requireSandbox.js ln144.
It will print the error message clearly. "Error: Cannot find module '..'"
Loopback use require('..') everywhere.

And Jsreport eat that error message. So, I can only see error "TypeError: test.printTest is not a function".

I had a workaround.
In node_modules@jsreport\jsreport-core\lib\worker\sandbox\isolatedRequire.js ln35. Change the code like this.
let newModuleId = moduleId === '..' ? '../index' : moduleId;

const fullModulePath = resolveFilename(ISOLATED_REQUIRE_RESOLVE_CACHE, requireFromRootDirectory.resolve, newModuleId, { parentModulePath: parentModule?.path })

It is not a solution, but I did not figure out why your isolate require does not support require('..').
Please do provide us a solution. Thank you!
@admin @jan_blaha @bjrmatos

bjrmatos

hi @JoeyLi-1

is the demo supposed to be down? https://github.com/Davidliu11/jsreport-test returns 404 for me

JoeyLi-1

https://github.com/77chuachua/jsreport-test Please try this one.
Sorry! Just realized that repo is private, that might because our company's policy. @bjrmatos

bjrmatos

thanks for the update, we are checking the problem

bjrmatos

i found that this is actually a node.js bug present in require.resolve, which is api we use to implement isolated modules. until they fix it, i have added a workarounds for it to resolve normally. this is fixed and it will be part of next jsreport release.

for the record, after fixing the bug i noticed that i was not able to finish the render of your template, i was getting browser error Failed to initialize WebGL which is related to the usage of mapbox-gl, what worked for my machine (macos with Apple silicon) was to use chrome arg "--use-angle=gl", maybe it is not needed on your machine but i just wanted to share what worked for me in case you need it.

this is the final jsreport.config.json that i've used

{
  "httpPort": 5488,
  "store": {
    "provider": "fs"
  },
  "blobStorage": {
    "provider": "fs"
  },
  "logger": {
    "console": {
      "transport": "console",
      "level": "debug"
    },
    "file": {
      "transport": "file",
      "level": "info",
      "filename": "logs/reporter.log"
    },
    "error": {
      "transport": "file",
      "level": "error",
      "filename": "logs/error.log"
    }
  },
  "trustUserCode": true,
  "reportTimeout": 60000,
  "workers": {
    "numberOfWorkers": 1
  },
  "extensions": {
    "authentication": {
      "cookieSession": {},
      "admin": {
        "username": "admin",
        "password": "password"
      },
      "enabled": false
    },
    "sample-template": {
      "createSamples": true
    },
    "chrome-pdf": {
      "launchOptions": {
          "args": ["--no-sandbox", "--window-size=1800,1350", "--use-angle=gl"]
      },
      "strategy": "chrome-pool",
      "allowLocalFilesAccess": true,
      "numberOfWorkers": 3
    },
    "assets": {
      "allowedFiles": "**/*.*",
      "searchOnDiskIfNotFoundInStore": true,
      "publicAccessEnabled": true,
      "rootUrlForLinks": "file:///Volumes/DATA/workspace/jsreport-bug-with-specific-require-in-isolated-modules/data"
    }
  }
}

JoeyLi-1

Yep. That "Failed to initialize WebGL" is known issue for us. We already have solution for that.

Looking forward to the next release. Thanks a lot! @bjrmatos