Great news, many thanks...

Hi Jan,

Any update on this?

We have a report which contains more or less an "optional" component template. If the template exists on a specific path we print it, if not, we don't want to get an error in the report throw new Error(``Component ${path} not found``)

Therefore we created a handlebar conditional which returns the options.fn(this) if the template is found and we call the component helper to print the component.
Up to jsreport 4.2.x this just worked fine and the component content was printed, since jsreport 4.3.0 the component block just returns a string (I guess an object reference).

  {{#componentExists "./components/student"}}
    {{component "./components/student" classRoomDetail=(findClassRoomDetail classRoom)}}
  {{/componentExists}}

const jsreport = require('jsreport-proxy');
async function componentExists(componentName, options) {
    const component = await jsreport.folders.resolveEntityFromPath(componentName, 'components');
    return component ? options.fn(this): options.inverse(this);
}

I'm thankful for any advice why this is happening and/or how the original behavior can be recreated (printing the component content).

Here's a running example of our report setup. The works in jsreport 4.2.x
https://playground.jsreport.net/w/ThomasJReiter/~ejVYSVP

We're doing this via a build pipeline during master build, but could also be scheduled, and use the jsreport api to export all reports we have and publish them to an artifactory. We're using gitlab and our pipeline has following jobs. Would this be a solution?

build jsrexport:
    stage: build
    image:
        name: <jsreport-docker-image>
    script:
        - echo "### BUILD JSREPORT EXPORT FILE"
       # all our jsreport templates are in the folder 'templates' and it's sub folders
       # the jsreport working directory is app/data in our case
        - cp -r templates /app/data
        - cd /app
        - jsreport export $CI_PROJECT_DIR/export-full.jsrexport
    artifacts:
        expire_in: 3 days
        paths:
            - '**/export-full.jsrexport'

publish jsrexport:
    stage: publish
    image:
        name: <some docker image with curl>
    script:
        - curl --fail -u ${USER}:${PASSWORD} -X PUT https://<where_we_put_it>/export-full.jsrexport -T $CI_PROJECT_DIR/export-full.jsrexport       

Hi,

Are you running jsreport directly in WSL2 or with docker/podman?
I had a similar problem with a rootless podman installation, and therefore changed to a simple docker solution. Then I was able to mount the automated mounted folders in WSL "/mnt/c/..." to my docker container and enable the direct synchronization.

Docker in WSL
https://dev.to/bowmanjd/install-docker-on-windows-wsl-without-docker-desktop-34m9

Docker Command
docker run -e "licenseKey=$LICENSE_KEY" -p 5488:5488 -v /mnt/c/.../templates:/opt/jsreport/data jsreport/jsreport

For me it would be fine to stay with your current implementation and document the use-case somewhere in a how-to.

Currently our complex case is implemented like this.

async function translateWithFallback(key) {
    const template = jsreport.req.template
    const templatePath = await jsreport.folders.resolveEntityPath(template, 'templates')
    const folderPath = templatePath.substring(0, templatePath.lastIndexOf('/'))

    return jsreport.localization.localize(key, folderPath + '/translations')
        .then(translation => {
            return !translation ? fallbackTranslation(key) : translation
        })
        .catch((e) => fallbackTranslation(key));
}

function fallbackTranslation(key) {
    const defaultDataPath = "translations/en.json";
    return jsreport.folders.resolveEntityFromPath(defaultDataPath, 'assets')
        .then(function(resolvedValue) {
            return JSON.parse(resolvedValue.entity.content.toString());
        })
        .then(function(data) {
            var v = data[key]
            return !v ?  "[" + key + "]" : "*" + v;
        })
}

Of course neither capable of special translation folders nor any other fallback language then English.

Thanks for the clarification.

What I meant was that we fallback for each translation individually. If not found in the given language we search in english and if we don't find it there we return the [key] instead of undefined. Outlined in reportB of the example.
https://playground.jsreport.net/w/anon/K78DqxIW

Thanks for the fast response, works well.

Just out of curiosity, are you considering a fallback to a default localization if no language is found? Currently an exception is thrown and the whole report won't build.

Edit: I added our fallback handling in the playground example from above.

Hi,

Our template structure looks like this

Besides other functions we have a translate function in our global-helper.js since all our localization is located in a sub-folder translation, it''s quite handy in a report templates to write {{translate "text"}}.

const jsreport = require('jsreport-proxy');

function translate(key) {
    return jsreport.localization.localize(key, "translations");
}

Since the upgrade to jsreport 3.3.0 we face the following error message with our setup.

Report "reportB" render failed.

Error when evaluating engine handlebars for template /reportB/reportB
localize helper couldn't find asset with data at translations/en.json
Error: localize helper couldn't find asset with data at translations/en.json
    at Object.localize (/app/node_modules/@jsreport/jsreport-localization/lib/worker.js:44:17)
    at async /app/node_modules/@jsreport/jsreport-core/lib/worker/render/executeEngine.js:133:40
    at async Promise.all (index 0)
    at async executionFn (/app/node_modules/@jsreport/jsreport-core/lib/worker/render/executeEngine.js:132:9)

Are we doing something wrong? Was this changed from 3.2.0 to 3.3.0 and if so, is there a possibility to fix this? Is there another way to solve the situation?

The release notes of 3.3.0 state "fix not resolving relative path correctly when calling asset code from another asset". Is this maybe the reason?

You can find a setup here

Thanks in advance for any advice.