Tauri is young in development but offers a lot already. Initially I used Electron and couldn’t make a normal build that would package my app properly so I gave up. Then I discovered Tauri. It does everything you need with a single command which is awesome!

I just compiled the examples in release mode (cargo build --examples --release) and the executables are around 2.2MB, that is amazing!

Here is what Tauri currently dynamically links, which is perfectly fine.

Can't wait to see more apps using it!

    % otool -L helloworld
    helloworld:
        /System/Library/Frameworks/WebKit.framework/Versions/A/WebKit (compatibility version 1.0.0, current version 613.1.17)
        /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices (compatibility version 1.0.0, current version 56.0.0)
        /System/Library/Frameworks/CoreGraphics.framework/Versions/A/CoreGraphics (compatibility version 64.0.0, current version 1557.5.4)
        /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1858.112.0)
        /System/Library/Frameworks/Carbon.framework/Versions/A/Carbon (compatibility version 2.0.0, current version 165.0.0)
        /System/Library/Frameworks/CoreVideo.framework/Versions/A/CoreVideo (compatibility version 1.2.0, current version 1.5.0)
        /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit (compatibility version 45.0.0, current version 2113.40.126)
        /System/Library/Frameworks/QuartzCore.framework/Versions/A/QuartzCore (compatibility version 1.2.0, current version 1.11.0)
        /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 1858.112.0)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1311.100.3)
        /usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0)
        /System/Library/Frameworks/Security.framework/Versions/A/Security (compatibility version 1.0.0, current version 60158.100.133)
        /usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0)
        /usr/lib/libresolv.9.dylib (compatibility version 1.0.0, current version 1.0.0)
        /System/Library/Frameworks/ColorSync.framework/Versions/A/ColorSync (compatibility version 1.0.0, current version 4.7.0)
        /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices (compatibility version 1.0.0, current version 1141.1.0)

Another thing I just tested using “includeexpr”, “path” and “suffixesadd” is that it is not possible (as far as my knowledge goes) to let vim open files correctly if the import path is a directory. Which my module does very well for javascript-like projects.

The main difference is that I want “fg” to be better, smarter to detect file paths. As I mentioned already, javacript-like projects use lots of absolute imports these days and these are not resolved by gf.

I am not sure if I get your point according to your reference, but the expression in your reference is way simpler than mine, although I should have used includeexpr rather than remapping fg itself. I’ll put that on my todo list, since that is the recommended way.