Closed Keyrxng closed 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?
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.
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
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.
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...
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.
I had some problems with ts-jest, can't remember exactly what, so I switched to @swc/jest
for kernel tests
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
Closing for now as I'm sure it's resolved, can reopen if it reappears.
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.
original context