Open Nigel2392 opened 1 year ago
Hi! This has been implemented on master. Details here: https://wails.io/docs/next/reference/cli#build
I think this has become an issue.
-devtools flag does not exist on my build...
It needs to be specified without the dash. Then it works. The command does not show up in the help menu.
See:
PS C:\Users\Nigel\Desktop\Tickets\tokens\__ideas\desktop_app> wails doctor
DEB | Using go webview2loader
Wails CLI v2.5.1
SUCCESS Done.
# System
OS | Windows 10 Home
Version | 2009 (Build: 22621)
ID | 22H2
Go Version | go1.20.2
Platform | windows
Architecture | amd64
# Wails
Version | v2.5.1
# Dependencies
Dependency | Package Name | Status | Version
WebView2 | N/A | Installed | 114.0.1823.51
Nodejs | N/A | Installed | 18.15.0
npm | N/A | Installed | 9.5.0
*upx | N/A | Available |
*nsis | N/A | Available |
* - Optional Dependency
# Diagnosis
Your system is ready for Wails development!
Optional package(s) installation details:
- upx : Available at https://upx.github.io/
- nsis : More info at https://wails.io/docs/guides/windows-installer/
♥ If Wails is useful to you or your company, please consider sponsoring the project:
https://github.com/sponsors/leaanthony
PS C:\Users\Nigel\Desktop\Tickets\tokens\__ideas\desktop_app> wails build -devtools .
DEB | Using go webview2loader
ERROR Error: flag provided but not defined: -devtools
See 'Wails build --help' for usage
♥ If Wails is useful to you or your company, please consider sponsoring the project:
The following help commands are listed:
Wails build - Builds the application
Flags:
-clean
Clean the bin directory before building
-compiler string
Use a different go compiler to build, eg go1.15beta1 (default "go")
-debug
Builds the application in debug mode
-dryrun
Prints the build command without executing it
-f Force build of application
-garbleargs string
Arguments to pass to garble (default "-literals -tiny -seed=random")
-help
Get help on the 'wails build' command.
-ldflags string
Additional ldflags to pass to the compiler
-m Skip mod tidy before compile
-noPackage
Skips platform specific packaging
-nocolour
Disable colour in output
-nosyncgomod
Don't sync go.mod
-nsis
Generate NSIS installer for Windows
-o string
Output filename
-obfuscated
Code obfuscation of bound Wails methods
-platform string
Platform to target. Comma separate multiple platforms (default "windows/amd64")
-race
Build with Go's race detector
-s Skips building the frontend
-skipbindings
Skips generation of bindings
-tags string
Build tags to pass to Go compiler. Must be quoted. Space or comma (but not both) separated
-trimpath
Remove all file system paths from the resulting executable
-u Updates go.mod to use the same Wails version as the CLI
-upx
Compress final binary with UPX (if installed)
-upxflags string
Flags to pass to upx
-v int
Verbosity level (0 = quiet, 1 = normal, 2 = verbose) (default 1)
-webview2 string
WebView2 installer strategy: download,embed,browser,error (default "download")
-windowsconsole
Keep the console when building for Windows
This is also not completely what I want. Are you sure there is no function to call? I do not mind linking. If there is, what package of the sourcecode might I find it in?
@Nigel2392 The -devtools
flag was just recently added in #2725, This is not released yet, so to test it, you will need to follow these instructions to build using master
.
Although, this not exactly what you're asking for, this will show the context menu along with the devtools when you right-click.
I was thinking of adding a runtime function to programmatically open the devtools in production when the devtools/context-menu is not enabled.
I did some testing and I was able to do so on Windows, but on Linux it only worked when the devtools is enabled, on Mac the code that is responsible for opening the devtools is only included in debug mode because it uses private API (I'm not a Mac user/dev so I don't know what's that)
@stffabi You wrote this code, what do you think? is it not possible to open the devtools on Mac in production? what about Linux, do you know if it's possible when the devtools isn't enabled like in Windows?
For context on private APIs: they are APIs that are there, physically callable, but there's no docs and absolutely no guarantees that it will continue working. On top of that, any app that uses one will never pass Apple's app store verification. So it's fine to use if you don't mind it breaking at some point and you're not publishing it.
@Nigel2392 The
-devtools
flag was just recently added in #2725, This is not released yet, so to test it, you will need to follow these instructions to build usingmaster
.Although, this not exactly what you're asking for, this will show the context menu along with the devtools when you right-click.
I was thinking of adding a runtime function to programmatically open the devtools in production when the devtools/context-menu is not enabled.
@stffabi You wrote this code, what do you think? is it not possible to open the devtools on Mac in production? what about Linux, do you know if it's possible when the devtools isn't enabled like in Windows?
Ahh, thanks! Did not see it was for a future release, now I do.
I did some testing and I was able to do so on Windows, but on Linux it only worked when the devtools is enabled, on Mac the code that is responsible for opening the devtools is only included in debug mode because it uses private API (I'm not a Mac user/dev so I don't know what's that)
Mind sharing where I can find your concept of opening devtools on Windows/linux through a function call? Sounds interesting!
Got it, so Mac is out of the question, maybe we could still add this function but it will work according to the platform, if you're on Windows it will always work, on Linux it will work if you build using -devtools
or -debug
, on Mac it will only work in -debug
, what do you think? is it worth it?
Mind sharing where I can find your concept of opening devtools on Windows/linux through a function call? Sounds interesting!
I'm testing on a local fork of Wails, it's not something you can do in your application code.
We could consider a function but it has to be explicitly enabled. But yeah, is there the demand for it vs the complexity of doing it?
It's not complex at all, it will just be a runtime function that calls an already existing code on each platform.
but it has to be explicitly enabled
It doesn't need an option to enable it, it's just a runtime function, if you need it you call it, say you have an admin area, you can have a button there to open the devtools, it will be most useful on Windows only because you could ship the application with no devtools and still be able to programmatically open in with a password or something.
Edit:
I need to add that most of the work is already done by @stffabi in the code for the option OpenInspectorOnStartup
(#2080) that's why it's simple to add this functionality.
Let's keep this open and if there's more demand for it I could issue a PR.
The reason I said "you'd need to enable it" is to ensure that by default it doesn't compile in code that calls private APIs. So we may need to hide it behind a build flag. I'd be interested to know if the code is still in the binary, even if it's not enabled in the config (I doubt the DCE is that good). Can be tested by adding println("I should not be here")
in that method then searching for the string in the binary
It's already hidden behind dev || debug
build flag and not included in a production
build :
And in production
it only includes an empty function :
So in summary, calling this function in dev
or debug
would open the devtools, while calling it in production
would do nothing and the private APIs won't be included, if I understand correctly (I'm a Go noob after all).
Hey guys, I need this feature. On the production build, I'd like to enter password or other backdoor to open devtools window. This could greatly help on debugging production build
Is your feature request related to a problem? Please describe.
Sometimes in your production environments; it can be handy to still have an option to open the devtools. I say; let the developer choose!
Describe the solution you'd like
Through a custom function in the runtime, possibly only allowed to call the function if a specific application configuration setting is set. The setting might seem redundant, but it could keep developers from making mistakes.
This way a developer can implement their own way to enable a simple debug mode in a production environment, without actually running their app in debug.
This could make the life of tech-support employees or developers easier; allowing them to find the root cause of errors more quickly
Describe alternatives you've considered
None. Deploying in a production environment with debug mode is a no-go.
Additional context
No response