ubiquity-os / ubiquity-os-kernel

1 stars 19 forks source link

SDK consumption #165

Closed Keyrxng closed 3 weeks ago

Keyrxng commented 3 weeks ago

Consumers of the SDK package are facing issues with build exports.

I have suggested, tested and failed to find a resolution with the approach of splitting the simple exports into their own file so no build breaking imports are present, although this seems like a fix for my specific scenario as I only needed the config paths but consumers of the complex function exports will probs experience this too. Ultimately I did not find a solution with this approach so I'm unsure without further debugging how to resolve.

I've spent about 4 hours already trying to find a focused solution that had minimal changes with no luck.

image

original context

whilefoo commented 3 weeks ago

I don't understand why this happens only when you use a version newer than v2.2.0. I checked the diff between v2.2.0 and v2.3.0 and there's no changes to the package.json, just some code changes so I don't even know where to start looking for a fix.

@Keyrxng can you confirm that it works with v2.2.0 on your end?

gentlementlegen commented 3 weeks ago

The error above indicates that no default export is found in the file. But this looks like the module was loaded as a CJS rather than an ESM. How were you trying to run the plugin @Keyrxng ? You can try adding export {} at the end of the file. Otherwise there is an option in tsconfig.json to allow for files without default exports.

whilefoo commented 3 weeks ago

I tried running with npx tsx ./src/main.ts locally and with Actions, both giving the same error

I've just checked the webhook-methods and it looks like it's in ESM format so I changed my plugin's package.json to ESM with type: "module" and the error changed to:

import { createActionsPlugin } from "@ubiquity-os/ubiquity-os-kernel";
         ^

SyntaxError: The requested module '@ubiquity-os/ubiquity-os-kernel' does not provide an export named 'createActionsPlugin'
    at ModuleJob._instantiate (node:internal/modules/esm/module_job:132:21)
    at async ModuleJob.run (node:internal/modules/esm/module_job:214:5)
    at async ModuleLoader.import (node:internal/modules/esm/loader:329:24)
    at async loadESM (node:internal/process/esm_loader:34:7)
    at async handleMainPromise (node:internal/modules/run_main:113:12)

Node.js v20.10.0

When I checked the ubiquity-os-kernel in node_modules, it clearly is exported

Finally success, cleaned node_modules and updated to v2.4.0 and with type: "module" it finally works

gentlementlegen commented 3 weeks ago

ESM is very painful to use. And many packages from Octokit are not fully migrated to ESM and cause various problems. It gets even worse when using them through Jest, or much worse when using experimental node features on Windows architecture (I always need to switch to Linux to have it working). I wonder if bun fixes this.

whilefoo commented 3 weeks ago

Yeah it's really a pain to work with Javascript sometimes, some libraries export only CJS, some export only ESM, but it seems it's best to use ESM because it can import CJS, but Jest has experimental support for ESM...

gentlementlegen commented 3 weeks ago

Jest has been working OK as long as you enable experimental features and specify to load everything as ESM in ts-jest configuration. However these experimental features do not work at all on non-Linux architectures. At least it passes the tests on the runners.

whilefoo commented 3 weeks ago

I had some problems with ts-jest, can't remember exactly what, so I switched to @swc/jest for kernel tests

gentlementlegen commented 3 weeks ago

Didn't know that it existed, will try it out! They seems to use the same logic as ts-jest for ESM runs: https://swc.rs/docs/usage/jest#q-jest-uses-commonjs-by-default-but-i-want-to-use-esm

Keyrxng commented 3 weeks ago

Closing for now as I'm sure it's resolved, can reopen if it reappears.