search

livebud / bud

The Full-Stack Web Framework for Go
MIT License
5.58k stars 179 forks source link

new fork to exclude external commits #85

Closed syke99 closed 2 years ago

syke99 commented 2 years ago

This should remove the commits to other files being tied to the PR like the previous PR for this fix was experiencing.

syke99 commented 2 years ago

This PR has been converted to a draft as I need to continue getting the example Make command targets to work with Windows. (The npm link command is failing to find the package.json. It's malforming the path, so may need to remove Make with Chocolatey and re-install another way) The bujs.ci, budjs.check, and budjs.test Make command targets may not work and will need to be tested as well.

syke99 commented 2 years ago

It ended up not being a corrupted make issue, rather than a make-on-Windows-specific issue with needing to separate (cd example/basic && ../../livebud) into 

cd example/basic
npm link
npm ../livebud

as I found out each line in a Makefile runs in its own subshell, so it wasn't looking in the right place for the top-level package.json file

Running any of the make example.* commands will still fail due to the syscall in package/socket/child.go, but I have a fix for that (that will work up to the point of v8go failing) ready to be put into a PR once this PR is approved and merged and I can fork bud again

matthewmueller commented 2 years ago

Hey @syke99, thank you for the effort. I must admit, the more I reflect on these changes, the more concerned I get.

We're making the Makefile more fragile for our current target users (OSX and Linux) while trying to adapt it for a platform we currently don't support. We still have some large hills to climb in order to properly support Windows (V8 support & passing file descriptors between binaries).

As I look to Laravel, I see that they also recommend using Laravel with WSL2 and it's not clear that they support Windows native. We're far from the capabilities of Laravel and I'd like to focus our effort on catching up before expanding platforms.

What do you think? I'd still like to support native Windows at some point, it's one of the key benefits of using Go, I just don't think we have enough usage or expertise yet to add proper support for the platform.

If the above makes sense, I have some suggestions:

Sorry if this comes as an unhappy surprise. I spent some more time thinking about it and it crossed the comfort to uncomfortable threshold 😓

syke99 commented 2 years ago

Hey Matt, I’m 100% okay with just adding a note in the README for users to just use WSL2. Honestly, getting native Windows development to work is going to be a HEAVY lift, especially with the v8 and the file descriptors/handlers. It’s something I’d still like to tinker with, but I’m definitely alright with not putting nearly as much focus on it right now!!

matthewmueller commented 2 years ago

Sounds good, thanks @syke99. Closing this PR then, but I'd be open to adding a note in the contributor guide for native Windows users!