Build error: Message SKD uses node specific import

[NilsJacobsen]

When types get imported via @inlang/sdk in the settings component, it can't get build anymore, because it's not build for "--platform=node".

Error: R] Could not resolve "node:crypto"

    ../../../lix/source-code/client/dist/hash.js:6:34:
      6 │         usedCrypto = await import("node:crypto");
        ╵                                   ~~~~~~~~~~~~~

The package "node:crypto" wasn't found on the file system but is built into node. Are you trying to bundle for node? You can use "--platform=node" to do that, which will remove this error.

The problem origined on the lix side: with the hash.js file.

[linear]

MESDK-39 Build error: Message SKD uses node specific import

[samuelstroschein]

@nils.jacobsen this is a lix issue no?

[samuelstroschein]

move this issue to lix-sdk?

[linear]

LIX-36 Build error: Message SKD uses node specific import

[samuelstroschein]

The typescript compiler likely detects the node import and throws.

A quick-fix could be to trick the typescript compiler. @jan.johannes @nils.jacobsen can you try this fix below in the lix sdk code?

-await import("node:crypto")
+await import("no" + "de" + ":crypto")

[janfjohannes]

resolved by using esbuild --external configuration. cause was building for browser with esbuild but esbuild had no way to know the dynamic import will never be active in browser environment

[NilsJacobsen]

Thanks @jan.johannes gonna fix it.

[samuelstroschein]

@jan.johannes why not use the hack i proposed?

it seems like your --external proposal now requires every lix app do know about this and add it to their build step? my proposal likely avoids that every lix app needs to build with --external. the problem is scoped to the lix sdk, not leaked to lix apps

[janfjohannes]

@samuelstroschein the hack does not work and this is the official esbuild solution. the only reason this is a problem is because tree shaking is still broken in our build, by the time we let lix be used by other apps this needs to be solved anyways.

[janfjohannes]

@nils.jacobsen @samuel.stroschein actually i just found a much better solution. the --external will be obsolete after the next lix release node exposes the module as globalThis.crypto too

[samuelstroschein]

@jan.johannes sounds like a one line code change. why not do it now?

[janfjohannes]

@samuelstroschein because it breaks tests for some reason, i need to find out why it works everywhere except in github actions :D

[janfjohannes]

ok so the globalThis was introduced in node 12 but only in node 19 do we get the crypto there. so for node 18 it only works with a command line flag. i moved to using the old method. but added a string interpolation into the dynamic import to try pushing esbuild into treating it as external. (i think thats what you meant by "no" + "de", but that does not work, ``node:${variable} should do the trick)

[samuelstroschein]

>(i think thats what you meant by "no" + "de", but that does not work, ``node:${variable} should do the trick)

Yes that's what i meant. I thought interpolation wouldn't be needed to achieve this but had in mind

[janfjohannes]

@samuel.stroschein anything should work as long as there is a variable added to a string in the process