Franjo Mindek

Yep, followed all of them: ``` ➜ ~ gpatch --version GNU patch 2.8 ➜ ~ diff -version diff (GNU diffutils) 3.12 ➜ ~ realpath --version realpath (GNU coreutils) 9.7 ```

Explore a bit and confirmed "Aliases and functions do not propagate to shell scripts. This is by design". We will need to handle OS differences in the script itself.

There is no real Github support for working with workflows from multiple repositories. If we want `starters` workflow to affect our `wasp` workflow, we need to use Github API to...

We don't test `wasp-app-runner` on changes to `wasp`, which is kinda bad, but then again to me it seems like `wasp-app-runner` would be less fragile to `wasp` changes than `starters`....

More about pointing haskell to right binaries, since user might have multiple versions installed, and might not have our version in path as default. e.g. `.vscode` ```jsonc { "haskell.manageHLS": "GHCup",...

That's what I meant, this configuration files should follow how we specify to set up the environment in our `waspc` readme. Any deviation from that and you should not expect...

That is a good point. How about limiting the scope to what is actually done on workspace level, rather than tampering with global configuration? e.g. we always store `ormolu` binary...

I think we can close this. I don't think there is a single perfect solution for this, and I don't think we want to enforce a certain approach to users....

Run into the same issue today, with npm git install: ```bash npm i -g https://github.com/wasp-lang/wasp-app-runner#80491aab8146823997e1f24aa92b045aa796d20d ``` ```jsonc // package.json // ... "build": "tsc", "prepare": "npm run build", // ... "devDependencies":...

> This issue covers several e2e test-related improvements: > > * We recently documented how a PR author should run e2e tests after getting the approval on the PR, but...