| 24 May 2026 |
alexfmpe | * the only ones that cares about the ghcjs package set itself are maintainers of it (this channel), or consumers that grab their deps with nix | 12:08:20 |
alexfmpe | I meant it's a special case amongs nixpkgs platforms as only ghc uses it, whereas most other pkgsCross.foo aren't specific to a language/compiler, since y'know, it's just a target platform | 12:13:10 |
tks_123 | alexfmpe ok thank you for clarifying | 12:19:46 |
tks_123 | This is very nice. Lots has happened in the past year | 12:22:04 |
alexfmpe | as for wasm backend, IIUC it has a lot of forked/vendored deps so https://github.com/NixOS/nixpkgs/pull/225000 never really got anywhere and ghc-wasm-meta is the main distribution method: https://gitlab.haskell.org/haskell-wasm/ghc-wasm-meta#getting-started-as-a-nix-flake | 12:28:01 |
tks_123 | alexfmpe As for HLS (vscode, etc.) should I put js backend programs and normal backend programs into different .cabal projects somehow? So HLS/cabal (somehow) knows which backend to use? (I'm assuming you can put both normal haskellPackages and and pkgsCross.ghcjs.haskellPackages into the same nix environment?) | 12:56:04 |
tks_123 | * alexfmpe As for HLS (vscode, etc.) should I put js backend programs and normal backend programs into different .cabal projects somehow? So HLS/cabal (somehow) knows which backend to use?I'm assuming you can (somehow) put both normal haskellPackages and and pkgsCross.ghcjs.haskellPackages into the same nix environment?) | 12:57:10 |
tks_123 | * alexfmpe As for HLS (vscode, etc.) should I put js backend programs and normal backend programs into different .cabal projects somehow? So HLS/cabal (somehow) knows which backend to use?I'm assuming you can (somehow) put both normal haskellPackages and and pkgsCross.ghcjs.haskellPackages into the same nix environment?) | 12:57:13 |
tks_123 | * alexfmpe As for HLS (vscode, etc.) should I put js backend programs and normal backend programs into different .cabal projects somehow? So HLS/cabal (somehow) knows which backend to use? I'm assuming you can (somehow) put both normal haskellPackages and and pkgsCross.ghcjs.haskellPackages into the same nix environment? | 12:57:24 |
tks_123 | * alexfmpe As for HLS (vscode, etc.) should I put js backend programs and normal backend programs into different .cabal projects somehow? So HLS/cabal (somehow) knows which backend to use? (I'm assuming you can (somehow) put both normal haskellPackages and and pkgsCross.ghcjs.haskellPackages into the same nix environment?) | 12:57:36 |
alexfmpe | You probably mostly want HLS only for native builds, if nothing else for speed | 12:58:17 |
alexfmpe | There's no ghci for js backend | 12:58:25 |
alexfmpe | I don't know if there's conflicts shoving both compiler/package sets in the same nix env, and it also depends on whether you just want the tooling from nix or also the dependencies | 13:00:15 |
alexfmpe | Safest thing might be to make the native backend the default, and have a separate shell for js builds | 13:01:03 |
alexfmpe | Past that you're into tinker-with-infra territory | 13:01:35 |
alexfmpe | This is a bit old in early-adopter terms, but might help as a reference: | 13:05:08 |
alexfmpe | https://github.com/bfeitknecht/impli/pull/6/changes#diff-93b556800e5bfe30a541d4c38712e88fc5763a362ab43de7446476ed3bddcee0 | 13:05:10 |
alexfmpe | Well, technically you can throw your package into the nixpkgs haskelloverides, and then nix-build like normal or with pkgsCross.ghcjs | 13:06:11 |
alexfmpe | But you asked about cabal.project so I assume you meant everyday local dev, not 'prod' build | 13:06:38 |
tks_123 | Yes, everyday local dev :) But... for everyday local dev, I'd want to... check if the website ... works in the browser (I guess)? | 13:08:19 |
tks_123 | * Yes, everyday local dev :) But... for everyday local dev, I'd want to... check if the website ... works in the browser. | 13:08:50 |
tks_123 | while also develop the website's frontend and backend (in vscode) | 13:09:20 |
tks_123 | (yes how the final thing is built is technically a separate question..) | 13:09:42 |
tks_123 | * while also developing the website's frontend and backend (in vscode) | 13:10:02 |
alexfmpe | Oh gotcha. Out of habit I was assuming jsaddle-warp for dev so the frontend would also be using native builds | 13:26:23 |
alexfmpe | But it sounds like you don't assume that for your project | 13:27:43 |
tks_123 | alexfmpe Hmm, it seems I was using jsaddle 2-3 years ago in my projects. it seems for some reason i wasn't aware of jsaddle-warp :S | 13:48:03 |
tks_123 | so i thought i had to always run a full ghcjs (the old ghcjs in this case) build just to preview my web apps... :S | 13:48:30 |
tks_123 | which makes me wonder, why i was even using jsaddle. Now i'm confused | 13:49:11 |
tks_123 | * which makes me wonder, why i was even using jsaddle | 13:49:29 |