Skip to content

Conversation

@wooorm-arcjet
Copy link
Member

@wooorm-arcjet wooorm-arcjet commented Sep 5, 2025

Since there is now a jco-transpile package with few dependencies (for 2 weeks), and that we’ve been stuck on an older jco to prevent package bloat, this PR attempts to unblock us by switching to the new package.

It seems to work! Their package is at 0.0.4 though, and the types a bit broken, but things pass. All options except for no-wasi-shim that were used are also in jco-transpile. I think that’s something that is wrapped around transpile. It could be some shim is injected though, I do not know enough about webassembly to verify whether some shim is in here.

Related-to: bytecodealliance/jco#500.
Related-to: GH-3446.
Related-to: GH-4342.
Closes GH-5101.

@wooorm-arcjet wooorm-arcjet requested a review from a team as a code owner September 5, 2025 09:45
@trunk-io
Copy link

trunk-io bot commented Sep 5, 2025

Merging to main in this repository is managed by Trunk.

  • To merge this pull request, check the box to the left or comment /trunk merge below.

@wooorm-arcjet
Copy link
Member Author

wooorm-arcjet commented Sep 5, 2025

Ah, Next/Webpack fails on some code that’s generated:

const isNode = typeof process !== 'undefined' && process.versions && process.versions.node;
let _fs;
async function fetchCompile (url) {
  if (isNode) {
    _fs = _fs || await import('node:fs/promises');
    return WebAssembly.compile(await _fs.readFile(url));
  }
  return fetch(url).then(WebAssembly.compileStreaming);
}

🤔

(from: https://github.com/bytecodealliance/jco/blame/cbaacb8fc9395366702b0bcf8dc07a99c85bc1ce/crates/js-component-bindgen/src/intrinsics/mod.rs#L472)

@socket-security
Copy link

socket-security bot commented Sep 5, 2025

Review the following changes in direct dependencies. Learn more about Socket for GitHub.

Diff Package Supply Chain
Security
Vulnerability Quality Maintenance License
Added@​bytecodealliance/​jco-transpile@​0.1.17910010095100
Updatedturbo@​2.6.1 ⏵ 2.6.310010084 -197 +2100

View full report

@socket-security
Copy link

socket-security bot commented Sep 5, 2025

Warning

Review the following alerts detected in dependencies.

According to your organization's Security Policy, it is recommended to resolve "Warn" alerts. Learn more about Socket for GitHub.

Action Severity Alert  (click "▶" to expand/collapse)
Warn High
License policy violation: npm @bytecodealliance/jco-transpile

License: Apache-2.0 WITH LLVM-exception - the applicable license policy does not allow this license exception (npm metadata)

License: Apache-2.0 WITH LLVM-exception - the applicable license policy does not allow this license exception (package/package.json)

From: package-lock.jsonnpm/@bytecodealliance/[email protected]

ℹ Read more on: This package | This alert | What is a license policy violation?

Next steps: Take a moment to review the security alert above. Review the linked package source code to understand the potential risk. Ensure the package is not malicious before proceeding. If you're unsure how to proceed, reach out to your security team or ask the Socket team for help at [email protected].

Suggestion: Find a package that does not violate your license policy or adjust your policy to allow this package's license.

Mark the package as acceptable risk. To ignore this alert only in this pull request, reply with the comment @SocketSecurity ignore npm/@bytecodealliance/[email protected]. You can also ignore all packages with @SocketSecurity ignore-all. To ignore an alert for all future pull requests, use Socket's Dashboard to change the triage state of this alert.

Warn High
License policy violation: npm @bytecodealliance/preview2-shim

License: Apache-2.0 WITH LLVM-exception - the applicable license policy does not allow this license exception (npm metadata)

License: Apache-2.0 WITH LLVM-exception - the applicable license policy does not allow this license exception (package/package.json)

From: package-lock.jsonnpm/@bytecodealliance/[email protected]npm/@bytecodealliance/[email protected]

ℹ Read more on: This package | This alert | What is a license policy violation?

Next steps: Take a moment to review the security alert above. Review the linked package source code to understand the potential risk. Ensure the package is not malicious before proceeding. If you're unsure how to proceed, reach out to your security team or ask the Socket team for help at [email protected].

Suggestion: Find a package that does not violate your license policy or adjust your policy to allow this package's license.

Mark the package as acceptable risk. To ignore this alert only in this pull request, reply with the comment @SocketSecurity ignore npm/@bytecodealliance/[email protected]. You can also ignore all packages with @SocketSecurity ignore-all. To ignore an alert for all future pull requests, use Socket's Dashboard to change the triage state of this alert.

View full report

@wooorm-arcjet
Copy link
Member Author

The transpile options today are:

 *   name: string,
 *   instantiation?: 'async' | 'sync',
 *   importBindings?: 'js' | 'optimized' | 'hybrid' | 'direct-optimized',
 *   map?: Record<string, string>,
 *   asyncMode?: string,
 *   asyncImports?: string[],
 *   asyncExports?: string[],
 *   asyncWasiImports?: string[],
 *   asyncWasiExports?: string[],
 *   validLiftingOptimization?: bool,
 *   tracing?: bool,
 *   nodejsCompat?: bool,
 *   tlaCompat?: bool,
 *   base64Cutoff?: bool,
 *   js?: bool,
 *   minify?: bool,
 *   optimize?: bool,
 *   namespacedExports?: bool,
 *   outDir?: string,
 *   multiMemory?: bool,
 *   experimentalIdlImports?: bool,
 *   optArgs?: string[],

So we could investigate whether we could use more of those

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I haven't dug into this in-depth yet but my feeling was that we'd put this into our pipeline as a Rollup plugin.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I’m a bit 🤷 on rollup: it currently doesn’t do much, it helps with WebAssembly, injects the current version, and builds .d.ts files. We could do more there. Or, perhaps we can do without it, and cut those dependencies?

In this case, these 2 duplicate scripts only needs to run when generating new WebAssembly, right?
So it could be a single script in the top-level monorepo?

Generating the version in a file could also be a simple node script.

And TS can generate types too (and we soon wouldn’t need it for our tests)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Rollup will continue to be used because it is the basis of the zero-dependency philosophy. We will remove all non-arcjet packages and then we will produce a single bundle for each SDK/Adapter that will contain the packages in this repo. Trying to move things out of the rollup pipeline will make this harder in the future.

Copy link
Contributor

@blaine-arcjet blaine-arcjet left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's build this as a rollup plugin to work towards the architectural goal of bundling adapters as a zero dependency package

Copy link
Contributor

@blaine-arcjet blaine-arcjet left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like the approach here. After reviewing the implementation, I wanted to look at the codegen since we've been behind and I think I found some non-starters. We will likely need to contribute fixes upstream before we can land this change if we don't want to apply more workarounds after transpile but before file-write.

Notably:

  1. It looks like wasi-p2 shim is being applied. We'll need a way to disable.
  2. The _debugLog looks at process.env which will need to be removed.
  3. Promise is shimmed, which would modify Arcjet users' runtimes.
  4. Titus mentioned the types are not generated as well as they used to be.
  5. ...Maybe other stuff I missed

}

if (!Promise.withResolvers) {
Promise.withResolvers = () => {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think we want to shim Promise in Arcjet user's runtime. This may be a non-starter unless we fix upstream.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I don’t see a reason why a library should do this.

It could be turned into a ponyfill function. Or alternatively, an option to turn it off?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Comment on lines +557 to +587
const _debugLog = (...args) => {
if (!globalThis?.process?.env?.JCO_DEBUG) { return; }
console.debug(...args);
};
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is going to cause warnings in Next.js targeting the Edge runtime. We had a problem before where static analysis was warning on any process.env access.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There seems to not be no option to turn debug logging off.
That could be a way to go.

Another one is, there is an option to turn off/on node compat. Defaulting to off, it injects this code when on.
Perhaps, when rendering the debug log, that option could be looked at, to not inject process.env stuff?

"bin": {
"wizer-win32-x64": "wizer"
}
"node_modules/@bytecodealliance/jco-transpile/node_modules/@bytecodealliance/preview2-shim": {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The wasi-p2 shim is still pulled in as a dependency so I worry that this is actually shimming WASI which we don't want to expose in our components since WASI allows for exiting the sandbox (which would be a security risk).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Passing wasiShim: false does not affect the output.
That is likely because it seems to be off by default: https://github.com/bytecodealliance/jco/blob/b3bc6266cfa521093afe8e563670a0b39d35715d/packages/jco-transpile/src/transpile.ts#L236

@blaine-arcjet blaine-arcjet marked this pull request as draft September 26, 2025 18:24
Since there is now a `jco-transpile` package with few dependencies (for 2 weeks),
and that we’ve been stuck on an older `jco` to prevent package bloat,
this PR attempts to unblock us by switching to the new package.

It seems to work! Their package is at `0.0.4` though, and the types a bit broken, but things pass.
All options except for `no-wasi-shim` that were used are also in `jco-transpile.
I think that’s something that is wrapped around `transpile`.
It could be some shim is injected though, I do not know enough about webassembly
to verify whether some shim is in here.

Related-to: bytecodealliance/jco#500.
Related-to: GH-3446.
Related-to: GH-4342.
Closes GH-5101.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Use jco-transpile

3 participants