Community
Chat Logs
Monday, May 18, 2026
- bluephaleth: hi, I just shoved out a big commit, but you cannot simply redeploy without changing some things. in particular, you probably need the docs and snippets directory
- phalethhi blue, ok I will make sure to test locally
- bluealso, it doesn't yet include your PRs. I'm gonna see if I can get target=static done for this release, so I'm holding off merging them for a bit
- bluethe markdown db/stores employ aggressive caching, so even if you redeploy at the current state, the website will be very fast, as fast as before
- phalethI should still do some changes on that PR if it's open
- blueyes
- phalethok, but that's not the reason for flash
- blueit'll also start up very fast in dev/prod, but that's a bit misleading: it sends off a promise to load/transpile the .mds, so it means that for the first 2-4 seconds after startup, requests may block
- phalethand currently there is still flash even when the cookie is handled server side
- blueya
- phalethfeel free to do whatever, I can always rebase
- phalethall I'm doing is learning primate
- phalethI should not hack on the core, even tho I'm looking through the code for sure
- bluethere are certainly areas I need to clean up. core contains a bit of old functionality from the time before esbuild
- phalethold code > new code
- blueha
- bluephaleth, wdyt about this
- blueinside app/config.ts, you can define entrypoints as a map
- blueso:
- blueentrypoints: { colorscheme: "client/colorscheme.js" },
- blueesbuild bundles client/colorscheme.js into client/colorscheme-SHA.js
- blueand %colorscheme% is available as a placeholder in html
- phalethbeautiful, but can I also prioritize them when the %head% is being put together?
- phaleththe thing is that one has to go before css
- blueyes, you'd be able to use %colorscheme% before %head%
- phalethoh, ok, but the entrypoint key name is still custom?
- blueyes, it'd be anything you want, aside from "head"
- blue%colorscheme% would typically expand to <script src="/colorschema-SHA.js"></script> or wahtever
- phalethok, then I guess it should throw if somebody tries to use head
- blueyes, it would throw if someone tries to use head or body
- bluebut essentially this would allow you to provide mini applications in your app
- blueand esbuild would be bundling it, so if you use imports in client/colorscheme.js, they'd be pulled in
- phalethsounds good, then I could ditch a lot of the code from the Website.ts
- blueya, probably
- blueI think the entrypoints idea is generally useful
- bluewe might then stop autobundling stuff from static
- bluealthough css might still need to be autobundled, because there's no good way to include it, unless you have like a base layout that does import
- bluemaybe I'm just old fashioned, I still think in terms of one central .css file you put in static
- bluebut the modern way to go is some kind of css split up across components or other such idiocy
- bluething is, primate currently supports both, and it's good that way
- blueif you place a css file in static, it will be bundled in, and if you have a <style> block in svelte or vue, it will be bundled in, and if you use some react library, probably too
- blueI think a coherent message is, static needs to remain static. anything you put in there is just going to be served as-is. that's the least surprising thing
- bluethen, via entrypoints, you have full freedom. you want a central css file? do `entrypoints: { css: "client/master.css" }`
- blueand use %css% in your html
- bluewhat do you think, phaleth?
- blueI think that's a lot more coherent than the current model
- blueand it still maps old 'central css/js' versus new 'logic/style spread across components' well
- phalethI've rebased the PR, brb, sorry
- phalethit's ready to be merged now btw
- bluealright
- blueI'll add the entrypoints feature first, then I think your PR would make most sense, since you get full control
- bluewe'd have { colorscheme: "colorscheme.js", css: "master.css" }, and then you can put %colorscheme% and %css% whereever you want in app.html
- blueand you put colorscheme.js, master.css and the fonts into `client`
- phalethwell, I can always do another PR
- phaleththat way I get to contribute more
- phalethand the current PR changes should work with the feature you are going to implement, you don't have to update the website while doing that, can leave that up to me
- phalethunless there is a gotcha, but I should be able to do that with your help
- phalethcss should be split just like js when there are chunks, yes
- phalethstatic should remain static as you note
- phalethI think splitting per components is dumb, but splitting per dynamic import is not
- phalethcause dynamic import is a choice, as well a build entrypoint is a choice
- phalethcomponents should just be razor thin anyway
- phalethwill the new entrypoint thing allow to have a second component tree?
- phaleth`entrypoints: { more-svelte: "client/MoreSvelte.svelte" }`
- bluephaleth: yes. what you put through entrypoints will go through the normal esbuild client server
- blueso if you got svelte registered as a module, it should know what to do with it. it does mean it might spit out both a js and a css tag in that case though
- blueesbuild client bundler*
- phaleththen that's ideal
- phalethbtw let me know when should I redeploy the website
- phalethlocally it works fine right now
- phaleththere is no change to the Containerfile
- bluebut the Containerfile needs snippets and docs to run now? they're now needed during runtime
- blueyou can deploy it now if you want. I won't finish the entrypoints thing today anyway, hopefully tomorrow and then I can merge the PR.
- phalethbut you will put them to the build dir?
- phaleththe build dir is what is being copied to the final image
- blueyes, so the Containerfile needs to copy them there
- blueand then we should test if it works in isolation
- phalethhmm? can the build system copy them? or not cause they are website specific?
- phalethit's a common practice to have everything in build dir
- phalethfor production build at least
- bluethe problem is markdown is now a db
- blueit doesn't participate in any aspect of the build system, at all, anymore
- bluethe build system bundles config/markdown.db.ts and the stores, but it doesn't bundle the data, that's in docs and snippets
- bluethe build system also only bundles config/markdown.db.ts and the stores because the routes import the stores. it's fully dynamic
- phalethok, then go ahead and merge and then I will update the Containerfile and redeploy
- bluehow does your PR currently work without flashing?
- phalethworks well on librewolf, palemoon and epiphany
- blueok -- but will be better with entrypoints, no?
- phalethnope, the scheme-storage.ts is now being bundled
- phalethas it's own separate chunk
- blueand then app.js dynamically loads it?
- phalethso the entrypoints feature is in no hurry
- phalethapp.html loads it
- bluebut how does esbuild know to bundle it if it's in client/scheme-storage.ts?
- phaleththere is an extra call to esbuild
- blueoh, in onBuild
- bluethat's the code you wanna eliminate once we have entrypoints
- bluegotcha
- phalethyeah, totally
- bluemerged it, testing it now
- blue(I'm really bad with testing PRs on github)
- phalethno worries, the master is supposed to be in flux anyway
- blueso right now if I copy build to /tmp/build and I run node server.js in it, it doesn't work
- bluesteps to make it work: copy docs and snippest to build
- blueand create a package.json file with { "type": "module" }
- bluethen it works
- bluethose are three things you need to do in Containerfile
- blue we won't need this in the future with target=static
- phalethpackage.json in build dir?
- bluebut for now it's needed
- blueyes
- phalethalright
- bluethis is because markdown.db.ts uses that to discover root
- blueso I don't see any flash locally
- bluelooks good to me
- phalethcool
- phaleththe image has built succesfully
- bluerock n roll
- bluehttps://gitea.repopack.app/repopack/provision/commit/31fd771390da5e957e1fe21f4afad8a5293a8b29
- bluelooks good
- phalethdeno is being picky: Uncaught (in promise) NotCapable: Requires read access to "/app/package.json", run again with the --allow-read flag
- phaleththere is no package.json in that dir, it's in the build dir, so should I make the same one there too?
- phaleththe /app dir is the root dir of the website
- phalethI can just copy the package.json to the image
- bluecan't you give it -A
- bluedeno is a PITA
- phalethnah, don't wanna do that
- phalethso if the dir does not exist it looks into build?
- phalethcause I'm getting another one Uncaught (in promise) NotCapable: Requires read access to "/app/docs", run again with the --allow-read flag
- phalethlooks like primate tries to look in there first
- phalethI will let it allow read everywhere then
- phalethactually not sure how to do that, but lets see
- blue-A
- phalethyeah, I gave up and trying with --allow-all now
- phalethcause I also need to go to sleep :D
- phalethgetting this error https://upaste.de/raw/Wm5
- phalethdeno is not involved in that, but maybe it's deno specific
- phalethso lets try node then
- bluephaleth: that means it didn't find the package.json
- bluethis depends on where you excute the command from
- phalethdeno build/server.js
- phalethnext to the build dir
- bluethen try placing the package.json and docs and snippets in . instead of build
- phalethok
- blueor just run deno from build directly
- bluethen it works too, just checked it locally
- bluedeno -A server.js (inside build)
- phalethok, lets see
- phalethI mean deno is great in making sure the deployment works
- phalethoh, a problem
- phalethok, I've switched back to the old container
- phalethlooks like the extraneous esbuild call didn't go well, I will investigate that tomorow
- phalethprolly deno's fault :)
- phaleththe new container is taking a lot of memory
- blueinteresting
- bluesignificantly more than the old one?
- phalethbtw, blue, can I ask you to update the OS and reboot the VPS?
- blueyes phaleth, can I reboot now?
- phaleththere is a new patch for linux kernel since saturday, but since that kids you out
- phalethyeah, sure
- bluedone
- phalethsignificantly more, yes
- bluewe're now on 7.0.9
- blueso the main difference between the old container and the new container is that previously, all the markdown files were bundled in
- bluethat means you only had to load server.js into memory
- bluenow I suppose it's loading all the .mds too into memory, though that shouldn't be significantly more
- bluewhat's the difference?
- blueI personally don't mind reverting the markdown db idea if it turns out to be a memory hog
- phalethcouple hundreds of megs I think
- blueoof, that's unacceptable really
- phalethcheck btop
- phalethyou will see three exe proceses and bellow also three exe processes
- phaleththe first three at the top are for the new container
- phaleththe second three are for the old container
- bluethree exe, each 487M?
- blueoof, the old one was 159M
- bluewhy is that three times btw
- phalethit's the isolation that does all those exes
- phalethbut yeah, memory hog
- phalethtime to crash, see ya
- bluewell, we need to find out why it's so bad, 159 -> 487 is over 3x
- blueotherwise markdowndb needs to be reverted
- bluealright, nighty night