Better Win support: correct resolving of node/npm/npx & prisma, no ANSI codes on Win #3258
Conversation
Martinsos
temporarily deployed
to
fly-deploy-test
GitHub Actions
Inactive
| prismaExecutableAbs = | ||
| waspProjectDir | ||
| </> nodeModulesDirInWaspProjectDir | ||
| </> SP.castRel (getPathToExecutableInNodeModules "prisma") |
There was a problem hiding this comment.
We are now being system-agnostic here, when figuring out abs path to prisma binary.
Martinsos
had a problem deploying
to
fly-deploy-test
GitHub Actions
Error
| {-# NOINLINE nodeExec #-} | ||
| nodeExec :: ExecName | ||
| nodeExec = | ||
| -- NOTE: We are taking whole resolved absolute path here because just using the resolved exec name |
There was a problem hiding this comment.
This I am not super happy with.
So basically just resolving npm to npm.cmd was not enough, we were still getting errors on Windows. Not the same ones, we moved forward, but different kind, I wish I wrote them down, something about not being able to find some .js files in node_modules.
But maybe it is for the best to have absolute paths to executables we use? Not 100% sure, I think if npm.cmd was working I woudl have stuck with it.
Interested in discussion here. Maybe I should try I again and write down the errors, that might help us make a decision.
| nodeExec = | ||
| -- NOTE: We are taking whole resolved absolute path here because just using the resolved exec name | ||
| -- was still flaky on Windows in some situations. | ||
| fromAbsFile $ snd $ unsafePerformIO $ resolveExecNameIO "node" |
There was a problem hiding this comment.
Instead of doing unsaferPerformIO, we could have actually obtained these in real IO, somweher at the start of our app, and then propagated them through the code, likely via our monad stack.
While that would be the "best" way to do it, I didn't think it makes much sense to bother with such big refactoring at the moment, for no real gain. We can do it if it turns out it is needed.
1 participant
TODO: