"main is not a function" with useless call stack
Closed this issue · 6 comments
I'm trying to switch from ts-node. To narrow down the issue I've deleted basically everything from my project
First I've built uni in my cloned copy at ~/dev/uni
My code is this branch here: https://github.com/AvenCloud/cloud/tree/uni-testing
I attempt to run ~/dev/uni/uni run lib/server/server.ts, and I see this unexplainable error- my code has no reference to "main"
At an earlier time, I saw a lib_uv error(!). But that was before I stripped down my reproduction example.
Usually I specify a custom tsconfig.json (tsconfig.server.json, while nextjs uses tsconfig.json).. and I couldn't figure out how to do that with uni.
Please see uni run --help
Sorry for the terse reply earlier, expanding:
main is something you must export from your script module. I'll document why somewhere, but in short, it's so that all files are safe to load - you need to explicitly run entrypoints by invoking main. uni run does that for you.
I've improved the error message here to explain you need main. Which is partially documented in the uni run --help output.
As for specifying a server tsconfig.json: Uni is only truly useful for node code right now, but I'm actively working on browser code support. I intend to automatically generate a tsconfig.json from some other config & expect it to be extremely minimal and will provide few to no options for further configuring it. You will have to modify your code to confirm to Uni's expectations, which will also eventually be documented.
Thanks for the help Brandon! This was a case of RTFM: not a drop-in replacement of ts-node edition
I'm happy to delete my tsconfig.server.json. As for browser code I currently am using next.js, which (conveniently) hides webpack. Aside from the slowness of webpack it seems to work fine alongside uni. So I probably can't test your progress on browser packaging until there is some support for next.
I'll experiment today with publishing packages from uni- the .d.ts exports are certainly important for me, which I know you're working on.
Uni + esbuild are so fast, this is a huge quality-of-life improvement!
Fair feedback, I'll probably write a "migration guide" at some point for folks coming from a range of similar tools.
As for Next.js: We're currently using it and are quite unhappy. It does a lot of magic that has caused us no end of pain, and so we're likely to abandon it altogether. It is unlikely for us to support their build idioms.
Ah, you're probably further down the Next.js packaging path than I am.. So I'm curious to hear what has gone wrong for you, and super curious how you might replace it.
In short, Next.js 1) uses Webpack, which is always a disaster & I want to get away from it 2) has a really weird model for SSR, routing, etc that has led to no end of problems with module state, code splitting, efficient page loading, client/server rendering sync issues, code reuse, layout & component identity for transitions, etc. This is even before we get to packaging, which is extra slow and complicated.