tools: bump @node-core/doc-kit from 1.0.2 to 1.3.3 in /tools/doc in the doc group

[dependabot]

Bumps the doc group in /tools/doc with 1 update: @node-core/doc-kit.

Updates @node-core/doc-kit from 1.0.2 to 1.2.0

Commits

• See full diff in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore <dependency name> major version will close this group update PR and stop Dependabot creating any more for the specific dependency's major version (unless you unignore this specific dependency's major version or upgrade to it yourself)
• @dependabot ignore <dependency name> minor version will close this group update PR and stop Dependabot creating any more for the specific dependency's minor version (unless you unignore this specific dependency's minor version or upgrade to it yourself)
• @dependabot ignore <dependency name> will close this group update PR and stop Dependabot creating any more for the specific dependency (unless you unignore this specific dependency or upgrade to it yourself)
• @dependabot unignore <dependency name> will remove all of the ignore conditions of the specified dependency
• @dependabot unignore <dependency name> <ignore condition> will remove the ignore condition of the specified dependency and ignore conditions

[nodejs-github-bot]

Review requested:

• @nodejs/web-infra

[ovflowd]

@avivkeller what's the latest version of doc-kit atm? Also tests failing 🤔

[avivkeller]

@avivkeller what's the latest version of doc-kit atm?

1.3.3

Also tests failing 🤔

Flaky tests, unrelated to doc-kit.

[ovflowd]

@avivkeller what's the latest version of doc-kit atm?

1.3.3

Also tests failing 🤔

Flaky tests, unrelated to doc-kit.

Will this PR automatically get updated to 1.3.3?

[kxxt]

Will this PR automatically get updated to 1.3.3?

IIRC @dependabot recreate will recreate a PR that bumps to latest version.

But since I need a bump to fix make test-only on RISC-V, I opened a PR to bump it manually here: #62686

[ovflowd]

@dependabot recreate

[ovflowd]

Will this PR automatically get updated to 1.3.3?

IIRC @dependabot recreate will recreate a PR that bumps to latest version.

But since I need a bump to fix make test-only on RISC-V, I opened a PR to bump it manually here: #62686

Didn't notice this was a PR managed by Dependabot, I thought we used our own Bot.

[avivkeller]

Didn't notice this was a PR managed by Dependabot, I thought we used our own Bot.

We use @nodejs-github-bot when a dependency isn't supported by Dependabot. When we first landed doc-kit, and used git deps, it wasn't supported by Dependabot, now that we release to npm, it is

[kxxt]

Now the dependency is bumped to latest, but the PR title and commit message is out of sync, which is a dependabot bug: dependabot/dependabot-core#4652.

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/72643/

[aduh95]

RuntimeError: memory access out of bounds on RHEL / linuxone CI

[sxa]

FYI @nodejs/platform-s390

[kxxt]

RuntimeError: memory access out of bounds on RHEL / linuxone CI

There's an s390x related change in nodejs/doc-kit#691 (comment) , would that be related or is it just flaky tests?

[miladfarca]

This issue seems to be related to Typed array usage under shikijs/engine-oniguruma/dist/index.mjs:
https://github.com/shikijs/shiki/blob/be89afcfb3bfaf8a29c0715bc13b3f95264ce87d/packages/engine-oniguruma/src/oniguruma/index.ts#L293
and
https://github.com/shikijs/shiki/blob/be89afcfb3bfaf8a29c0715bc13b3f95264ce87d/packages/engine-oniguruma/src/oniguruma/index.ts#L360

Wasm is little-endian enforced, Typed arrays follow native-endian order. If you manipulate a Wasm buffer you have to make sure data is also in little-endian format, i.e a fix would look something like this:

    /*const strPtrsPtr = onigBinding.omalloc(4 * patterns.length);
    onigBinding.HEAPU32.set(strPtrsArr, strPtrsPtr / 4);
    const strLenPtr = onigBinding.omalloc(4 * patterns.length);
    onigBinding.HEAPU32.set(strLenArr, strLenPtr / 4);
    */

    const strPtrsPtr = onigBinding.omalloc(4 * patterns.length);
    const strLenPtr = onigBinding.omalloc(4 * patterns.length);
    const dv = new DataView(onigBinding.HEAPU8.buffer);
    for (let i = 0; i < strPtrsArr.length; i++)
      dv.setUint32(strPtrsPtr + i * 4, strPtrsArr[i], true);
    for (let i = 0; i < strLenArr.length; i++)
      dv.setUint32(strLenPtr + i * 4, strLenArr[i], true);

...

  /*const HEAPU32 = onigBinding2.HEAPU32;
  let offset = resultPtr / 4;
  const index = HEAPU32[offset++];
  const count = HEAPU32[offset++];
  */

  const dv2 = new DataView(onigBinding2.HEAPU8.buffer);
  let byteOffset = resultPtr;
  const index = dv2.getUint32(byteOffset, true); byteOffset += 4;
  const count = dv2.getUint32(byteOffset, true); byteOffset += 4;
    const captureIndices = [];
    for (let i = 0; i < count; i++) {
      // const beg = string.convertUtf8OffsetToUtf16(HEAPU32[offset++]);
      // const end = string.convertUtf8OffsetToUtf16(HEAPU32[offset++]);
      const beg = string.convertUtf8OffsetToUtf16(dv2.getUint32(byteOffset, true)); byteOffset += 4;
      const end = string.convertUtf8OffsetToUtf16(dv2.getUint32(byteOffset, true)); byteOffset += 4;

Not sure if this glue code is generated with Emscripten or not, if it is then it needs to be regenerated with SUPPORT_BIG_ENDIAN=1 as explained under this fix: emscripten-core/emscripten#13413

[kxxt]

This issue seems to be related to Typed array usage under shikijs/engine-oniguruma/dist/index.mjs: https://github.com/shikijs/shiki/blob/be89afcfb3bfaf8a29c0715bc13b3f95264ce87d/packages/engine-oniguruma/src/oniguruma/index.ts#L293 and https://github.com/shikijs/shiki/blob/be89afcfb3bfaf8a29c0715bc13b3f95264ce87d/packages/engine-oniguruma/src/oniguruma/index.ts#L360

Wasm is little-endian enforced, Typed arrays follow native-endian order. If you manipulate a Wasm buffer you have to make sure data is also in little-endian format, i.e a fix would look something like this:

Thanks for investigating it!

Not sure if this glue code is generated with Emscripten or not, if it is then it needs to be regenerated with SUPPORT_BIG_ENDIAN=1 as explained under this fix: emscripten-core/emscripten#13413

The copyright header in the code tells me that this glue code in shiki is actually copied from https://github.com/microsoft/vscode-oniguruma/blob/main/src/index.ts. vscode-oniguruma indeed uses Emscripten but I cannot find where they generated the index.ts.

But given the complexity and delay involved in fixing code in two upstream repos, perhaps it's better to disable the wasm highlighter for s390x again in doc-kit.

[miladfarca]

But given the complexity and delay involved in fixing code in two upstream repos, perhaps it's better to disable the wasm highlighter for s390x again in doc-kit.

Yes it needs to be disabled on big endian platforms (s390x, AIX) until the upstream repositories are patched.

[ovflowd]

But given the complexity and delay involved in fixing code in two upstream repos, perhaps it's better to disable the wasm highlighter for s390x again in doc-kit.

Yes it needs to be disabled on big endian platforms (s390x, AIX) until the upstream repositories are patched.

So I suppose a patch to doc-kit to add s390 back to blocklist? And then another patch here https://github.com/microsoft/vscode-oniguruma/blob/main/scripts/build.sh#L3-L14?

[kxxt]

So I suppose a patch to doc-kit to add s390 back to blocklist?

I opened nodejs/doc-kit#769 for it.

[ovflowd]

I've also opened microsoft/vscode-oniguruma#43 upstream

[kxxt]

1.3.4 that disables wasm highlighter on big
-endian is available on npm. Could anyone with write access to this repo run @dependabot recreate to update this PR? Thanks.

[ovflowd]

@dependabot recreate

[ovflowd]

FYI vscode team pushed the change upstream, Ill wait for a new release and let the shiki folks know of the new version.

[ovflowd]

Side note: A few months ago I considered pushing this change to vscode-oniguruma but hesitated since I thought we did a workaround on our side. I should probably have done the PR anyways!