DEV Community: Tauri

Tauri 1.0 Release Candidate

Daniel Thompson-Yvetot — Thu, 10 Feb 2022 22:56:14 +0000

tl;dr;
We present the first release candidate of Tauri 1.0, and invite you to look at, comment upon, and try out the new features and security fixes that we are bringing to the table. After several RC iterations, we will release the stable version of 1.0.

https://github.com/tauri-apps/tauri/releases

Our Working Method

Over the past 8 months, we have been working together with the community (in public), and third party Security Auditors and Pentesters Radically Open Security (in private) to apply needed finish to Tauri Core. This includes not only usability features and fixing incomplete APIs, but also enhancing the overall security of the ecosystem and producing a number of official Tauri plugins.

Progress

Our current top priority for 1.0 is delivering a smooth process for not only setting up Tauri requirements on all development platforms, but also the creation of new Tauri projects. To acheive this we need to test it on as many platforms as possible, squash any bugs during a few RC versions, and enhance all of the documentation.

Usability

As developers ourselves, we want our tools to be ergonomic and easy to use without sacrificing on performance and security. One of the qualifying features that will enable us to release the stable 1.0 is a perfect tooling setup on all platforms without resorting to hacks or unsafe practices. We will be working on this over several iterations of the release candidates.

Documentation

We know that building on Tauri has been a hit or miss experience for many of you, and much of this has to do with outdated documentation. At the same time, the matrix of possible installation platforms for developers makes a system that is in flux makes it really challenging to get right.

Security Features

The auditors made a number of findings, which we have resolved and which were accepted in the post-audit review of our fixes. We are now confident that Tauri core is safe, and that we have provided fixes and features that enable the production of industrial-grade secure applications. You may read the full audit report here:
https://github.com/tauri-apps/tauri/blob/next/audits/Radically_Open_Security-v1-report.pdf

Next Steps

Please remember, that a release candidate seeks to qualify the codebase for a stable release. We are certain that we have missed things and probably have bugs. The complications of our CI mean that we will probably fight with the release process a few times. You may discover problems with the installation process, and even have minor issues with consuming the JS libraries. We are counting on you to help us solve (or at least discover) these concerns so they can be resolved and move Tauri as quickly as feasible to a full release.

Image by Alve

Sustaining Community

Daniel Thompson-Yvetot — Mon, 10 Jan 2022 14:59:03 +0000

Open source is a complex entity composed of not only lines of code and miles of documentation, but also a living being that is nurtured by people from all walks of life. Young or old, experienced or beginner, corporate or independent, cis or fluid, Eastern or Western. No matter which reasons we choose to build and use open source software, one thing is clear: Together we are stronger.

Tauri, by its nature, seeks to be inclusionary. Whether rust maximalist or typescript pro, vue or svelte, windows or linux, dominator or solidjs, frontend or backend — Tauri brings classically opposed and tribal communities together, because we know, deep in our hearts, that, just like ice cream, no modern framework is better than any other: It’s all just different flavours for different folks.

Obviously everyone has their own agenda, and seeks to further their own cause. And yet, by pulling on the same rope we are all moving toward a better system than we could ever make in proprietary isolation. This is the premise and promise of open source, and it is very clear that it works for Tauri. We are in the top 400 most starred projects on Github (out of 14million), we are about to release our horizontally and vertically audited 1.0 stable. We invite anyone interested to become a member of the working groups, and we are doing our best to stay transparent, remain accountable, and make the most elegant, secure, and resource-preserving system we can.

And yet in every family there can be stress, miscommunication, hurt feelings, and division. In open source, as with all types of community organising, there is not only a massive risk of burnout, but also alienation as a result of perceived entitlement. But the most terrible thing that can happen, is that volunteers work so hard at trying to help others, that they forget about not only taking care of themselves, but also that there are people on the other side of the screen who have real feelings. Frustration can boil over and they lash out to people who are just trying to get their problems solved.

Since Tauri’s inception, there have been several occasions where the tone of voice of some of us did not meet the mark of our own expectations of ourselves, and were in clear violation of our own Code of Conduct. This was even a thematic topic on Hacker News, where frustrated people shared their horrible experiences with the larger community. We are truly sorry for this, because we want to do better.

It was a signal to all of us on the Tauri Board of Directors that self-policing doesn’t scale. We urgently need to double down on helping our community take care of itself.

This is why today, we are making a call for a Lead Community Liason - a one or two-person team to help nurture the community, acting as role-models more than police, and assisting in the mediation of challenging acts of miscommunication. This role will be part time, can be done anywhere by anyone, and will be paid 100% from the donations that the community has made to the project. If you (or you and a friend) are interested in this freelancer position, love Tauri, and are able to write invoices to OPENCOLLECTIVE, please send your CV with relevant community experience to @nothingismagick on Discord. We will conduct interviews, and the final decision will be made by the Board of Directors.

Our hope is that by using donations to help the community be a safer and more inclusive space, that we are taking the right action to make Tauri a better and more sustainable Open Source project.

TAURI FEATURE FREEZE AND SECURITY AUDIT

Daniel Thompson-Yvetot — Tue, 24 Aug 2021 07:53:49 +0000

Security Audit Begins
Code Freeze In Place
next Branch in Progress

At a certain point in the lifecycle of software, you have to just stop and smell the roses. Or in this case, hunt for code smell. And that is what the Tauri team is doing. We will no longer be accepting any feature requests for the forthcoming 1.0 and only accepting bug reports. All new features will then be addressed in the next branch.

Why would we do this, you might be asking yourself. Well, before we can declare Tauri safe to use, we need to put it through the proverbial ringer - and gain confidence that it is not only architected properly, but also that common attack vectors are mitigated against and boundaries are protected.

After you've been spending years in the forest of your project, it is obvious that you might not see all the trees - or even its place in the greater ecosystem.

To this end, we are pleased to announce that the Tauri Programme within the Commons Conservancy has teamed up with the non-profit group of penetration testing experts at Radically Open Security to help us gain not only deeper insight into the entire project, but also acquire the confidence we need to recommend using Tauri in production.

The Audit consists of both a horizontal and vertical investigation. The horizontal audit will look into all of the crates and libraries that compose Tauri, as well as its tooling and pipelines. The vertical audit will investigate an example application (our examples/api app) on all three platforms to verify that it is safe to use and our security posture is both appropriate and safe.

At the conclusion of the audit, we will publish the findings and lock our 1.0 release to maintenance such as dependency updates and urgent fixes in case bugs are found. As mentioned above, all further work on new features like mobile and additional API's will be undertaken in the @next branch which will graduate to 2.0 upon its completed audit.

One last word of caution: Security audits are a regular practice of due diligence and they are not guarantees that everything is safe. Your app's security will have as much (if not more) to do with your coding practices than with Tauri's underlying security. If you are doing anything with private data or using cryptography, you would do well to have your project audited as well.

Disclaimer: It is important to understand the limits of the
Tauri team and Radically Open Security's services. The Tauri
team and Radically Open Security do not (and cannot) give
guarantees that something is secure. It remains the
responsibility of downstream engineers to ensure the 
security of the(ir) projects that use Tauri.

Announcing Tauri Beta - More efficient crossplatform apps with better features

Daniel Thompson-Yvetot — Wed, 12 May 2021 20:26:41 +0000

Hello fellow engineers, project managers, and technocrats! Today, after exactly two years of work, we are proud to announce the Beta release of Tauri 1.0.

Github Repository: https://github.com/tauri-apps/tauri
Website: https://tauri.studio

So, what Is Tauri?

Tauri enables you to make apps using the Webview technology stack that each operating system provides. It empowers you to call into the app backend using a JS api, which gives you opt-in access to things like the filesystem. All of this is done without needing to ship a localhost server and while maintaining a secure context for your application.

Tauri apps can have custom menus and tray-type interfaces. They can be updated securely, and are managed by the user's operating system as expected. Their ultimate binaries are very small, because they not only use the system's webview, they also do not need to ship a runtime (like Node.js), since the final binary is compiled from Rust. This makes Tauri apps quite small and performant, and also turns the reversing of Tauri apps into a task that is neither trivial nor fun.

If you want to find out more, we recommend checking out the intro on our website or diving into the architectural design document.

In short, Tauri is a toolkit for creating smaller, faster, and more secure desktop apps with a web frontend. Tauri's core system is written in stable Rust and currently uses that for the main process. However, you do not need to write Rust code to interact. Nevertheless, we plan on providing bindings to other languages after the full 1.0 release.

We are finally happy enough with its shape and approach that we are marking its status as Beta. This means that over the course of the next several months a few things are going to happen:

We will make sure it builds properly on all the platforms we want to support. This includes the major Desktops and the Major Mobile operating systems.
We will employ a third-party security consultancy to perform a horizontal security audit so that we can be confident that the core libraries are safe to use.
We will fix bugs that arise and work on reducing final bundle sizes as much as possible.

What's New?

So many things have changed that we can't fit the full list here. Instead, we'll just be summarising the biggest changes. If you want the gory details, visit our Release Notes.

However, if you already started a Tauri project back in the Alpha days, check out this migration page to get informed as to what you have to do to get back in the saddle.

WRY (Webview Rendering librarY)

Tauri Alpha used bindings to webview/webview, a C++ library. While these got the job done, they were quite buggy on Windows and were lacking a lot of features we wanted. We've replaced these with WRY, a new, pure Rust Webview library we developed for Tauri. WRY has proven to be much more stable on Windows, and adds the following features to all platforms:

Custom window styles: frameless, transparent, invisible, always-on-top
Height and width constraints
Draggable regions
Programmatic setting of: size and size constraints, window styles, minimized/maximized, title
Custom app menus
System tray support

TAO

For the first part of its existence, WRY depended on winit, the amazing Windowing provider for many operating systems. As time went on, however, we also need some advanced features like menubar and system tray which contradicted with their vision, and thus we made the hard decision to fork winit and republish it under a different name: TAO.

This means that the TAuri Organisation controls all first-order dependencies.

Rust CLI

We've moved almost every command to a new CLI, written in Rust. This means Node.js is no longer required for developing Tauri apps, although it is recommended for now (unless you have problems with node.js and compiling some of the libraries for imagemin). We'll be moving the final commands over soon, making the JS CLI a thing of the past. Want to test it while we are still in beta?

% cargo install tauri-cli --version ^1.0.0-beta
% cargo tauri --version
cargo-tauri 1.0.0-beta.0

`cargo run` Support

It is now possible to run your Tauri application with cargo run instead of through the Tauri CLI. This is possible through a new internal codegen crate that can generate everything required from your Tauri config file. This still requires you to have a valid tauri.conf.json along with whatever assets inside your distDir already generated. For the time being, the codegen will not run your beforeBuildCommand or beforeDevCommand from the config.

New Web Content Loader

We've removed both the no-server and embedded-server modes, and replaced them with a new custom protocol loader. This combines the security of the no-server mode with the stability of the embedded-server, and is more performant than both.

Multiwindow

It's finally here! Thanks to WRY's improved interface, we've been able to add one of the most requested features to Tauri. You can now create multiple windows, either at launch through tauri.conf.json or programatically through Rust. We've used this in our new Splashscreen Guide, which allows your app's web contents to load in the background while a splashscreen is displayed.

Improved Command Handling

We've added some macros that makes creating Rust commands as simple as writing a function:

// Defining commands is no longer a multi-file mess
#[tauri::command]
fn my_custom_command() {
  println!("I was invoked from JS!");
}

fn main() {
  tauri::Builder::default()
    // No need to write a fancy handler, either
    // Just pass in a list of all your commands
    .invoke_handler(tauri::generate_handler![my_custom_command])![generate](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/gpkroh61gxeho4aq1ivk.png)

    .run(tauri::generate_context!())
    .expect("error while running application");
}

// Calling your commands is super easy as well
import { invoke } from '@tauri-apps/api/tauri'
invoke('my_custom_command')

Tauri's command feature also supports passing arguments, returning values and errors, and running async functions.

Updater

We've added a new updater feature, allowing you to easily ship updates to your Tauri apps. You can create a custom update notification and progress indicator, or use the builtin update prompts. Updates are signed on publish and verified before installing, so users can be sure they aren't getting a malicious version of your app.

External Audit

We are working together with Doyensec to undertake a complete horizontal audit of the critical components of Tauri, Tao & Wry. Doyensec has a long history of analysing Electron apps, so they are extraordinarily qualified to investigate the issues surrounding desktop apps. Once the audit is completed and we have resolved any and all concerns raised by the auditors, we will have crossed the threshold to a stable ecosystem and the 1.0 release will follow. If you plan to use Tauri in production, please consider making a donation to our Open Collective fundraising campaign to support this expensive endeavour.

Get Started With Tauri

If you'd like to get started making apps with Tauri, check out our getting started guide. Within a few minutes, you'll have your first Tauri app up and running.

What Tauri does not

Tauri does not use Internet Explorer based Webviews, so there is no outdated Internet Explorer code being shipped in your app. (Seriously, stop spreading FUD.)
Tauri does not ship Node.js by default, and actually you don't even need to have Node.js installed on your machine to build Tauri apps. (You can in fact just use the Rust CLI, and even build your entire frontend with a WASM based system like YEW).
Tauri does not run a devserver for your HTML/CSS/JS framework. There are just too many of them and they change all the time, so it is not worth the maintenance burden.

Who is Tauri

The Tauri organisation aims to be a sustainable collective based on principles that guide sustainable free and open software communities. To this end it is currently becoming a Programme within the Commons Conservancy, and you can contribute financially via Open Collective.

What's Next?

We've got a lot planned for Tauri, like Arm/Android/iOS support, a testing framework, and binding to other languages for the main process. See our roadmap for the full list. If you'd like to help add these features to Tauri (or if you have any questions), we'd love for your to join our Discord Server at https://discord.gg/tauri . Let us know that you want to contribute, and we'll find a good task for you and guide you along.

You can also help us out by donating to our Open Collective, however if your company actually turns a profit using Tauri, you should really consider the benefits of becoming a platinum sponsor. And speaking of sponsoring... how many open source projects do you sponsor? We hear that Babel needs support.

Title Graphic: Alve Larsson

Use deno to build a Tauri App

Daniel Thompson-Yvetot — Sat, 13 Jun 2020 11:49:56 +0000

At Tauri we originally built our CLI with typescript and node.js, but we've been looking into alternatives for a while. In that vein, we just POC'd building a Tauri app with Deno (instead of node.js)

We won't explain how to install the toolchains (deno, rust and tauri), and expect you to have already built your first Tauri apps already. But if you are new to all of this, here are the details:

Rig and build!



git clone git@github.com:tauri-apps/tauri
cd tauri/cli
git clone git@github.com:lucasfernog/tauri-deno-cli deno
cd ../tauri/examples/communication
deno run --unstable --allow-read --allow-run --allow-net --allow-env --allow-write ../../../cli/deno/index.ts build

Benchmarking

The second time you run deno build, you'll have all the deps already installed and the rust crates as well, so let's see how long it takes on MacOS (this isn't a scientific bench):

deno

command



$ time deno run --unstable --allow-read --allow-run --allow-net --allow-env --allow-write ../../../cli/deno/index.ts build

with antibloat



real    1m2.738s

  user    0m42.514s

  sys     0m2.933s

no antibloat



real    0m25.001s

  user    0m16.473s

  sys     0m1.758s

no antibloat, just .app



real    0m5.906s

user    0m11.780s

sys     0m1.268s

node.js

command



$ time node ../../../cli/tauri.js/bin/tauri build

with antibloat



real    1m10.295s

  user    0m51.990s

  sys     0m3.009s

no antibloat



real    0m44.562s

  user    1m5.383s

  sys     0m3.187s

no antibloat, just .app



real    0m26.423s

user    0m59.936s

sys     0m2.805s

Discussion

The ~1 minute build time might seem like it takes a long time, but we are actually using these antibloat techniques only possible when single-threading.

Also, if you are trying this in your own project, you should know that you will have to run yarn tauri dev at least once in order to create index.tauri.html. We haven't started porting the inliner to deno.

Nevertheless, deno performs better in both cases - without antibloat almost twice as fast, and just building a .app its about 4.5x faster. So I absolutely have to agree with Lucas' sentiment:

deno is f!cking amazing

Setting Up CI and CD for Tauri

Jacob Bolda — Mon, 23 Mar 2020 13:49:59 +0000

Setting Up CI/CD for Tauri

Background

When Tauri hit my radar, it was pushing towards releasing an alpha. The repo did not have continuous integration or continuous delivery set up. I had seen the value that it can have in creating focus in a project. I knew I would be able to provide immediate value to the project with CI/CD.

Thus began my involvement. We decided to use the shiny new GitHub Actions to deliver this. It was still in beta, but it had gone through iterations over months and months. We felt it was stable enough to use (and nearly out of beta anyway). The deep integration with GitHub will be useful for us.

We didn't have much in the way of tests to run as much of the codebase had been more recently pulled out of other projects. The quickest win was to take and create some example projects. We could then create, what we're calling, our smoke tests on top of the examples. We took the manual process of testing in projects, and dumped . They are "integration" tests where we will take any HTML, CSS and JS and build it with Tauri.

Next Phase of Testing

This served us well and caught a few bugs in the process. We had the focus to get to and meet our release goal of launching the first alpha build. As the confidence in our code base has risen, the value has flipped. The time these smoke tests take to run has grown faster than to the value delivered. The time that it takes to run the smoke tests has become painful. We had these tests run on every push to a PR, as we wanted a tight feedback loop in fixing any issues we had. Now that we started to add more unit tests. We can back off and not run on every push while still getting the needed feedback. The next phase in our setup will be running our unit tests on every push, and dialing back our smoke test runs.

Github Actions has two triggers of which we make heavy use: push and pull_request. Every commit that made to the repo is a push. When you open a pull request from a branch (call it great_feature) to another branch (our working branch, dev), each commit to great_feature would possibly trigger both of these events. We can use a filter to focus on the events we care about though. In our workflows, we only PR (pull request) the dev and master branches. This means that if we filter to only the dev and master branches on commit, we will only run that workflow when we merge a PR. A merged PR typically only occurs once a day or less so this will be a good fit for the longer running tests, e.g. the smoke tests in our case. Below is how that might look.

Unit tests:

# these run fast so we can have them run on any commit
name: unit tests
on:
  pull_request:
  push:
    branches:
      - dev
      - master

Smoke tests:

# these run slower so we run only on merges to dev or master branch
name: smoke tests
on:
  push:
    branches:
      - dev
      - master

Tauri operates off the dev branch as default, and merges to master for release. With these Github Actions set up, we will run the unit tests on every commit to an open PR (see pull_request). When that PR is merged into dev, we will run both the unit tests and the smoke tests.

Our Examples (aka Smoke Tests)

Let us touch on this for a moment. The smoke tests are a handful of examples created using the major frameworks (Vue, create-react-app, Quasar, Next.js, Gatsby, ...). Originally these resided in a separate repository. They were then moved into the main Tauri repo for what seemed worthwhile benefits. We implemented the Renovate bot which opens a pull request to upgrade dependencies which includes our examples. Remember those Github Actions? This would trigger our tests to run. It was nice to see these tested every time our examples updated. Having the examples close by and wired up also made for testing locally much easier. The downside is that these pull requests created a lot of noise. The examples were flooding our CI and commit history. To help reduce the noise, we grouped updates into logical chunks and ran them on specific days. That helped but not quite enough.

Our Github Actions uses a "standard action" called actions/checkout which pulls in our repo. This was recently updated to v2, and with it came the feature which made it much easier to checkout multiple repos. This feature gave us enough incentive to shift the examples back into their own repository. We could still implement the update process and test using the examples, but the noise is removed. This changes the local dev workflow, but we can adapt to it.

Next Level Publishing

The next big value add that we will see is a programmatic release process. We can set up a system to release our packages to either crates or NPM. While this concept is not new, the difficulty that we are seeing is that none of these existing systems or command line programs are able to deal with a monorepo that has multiple languages. It gets even more involved if we want to release packages independent of one another. We looked at a CLI utility called bumped that takes a version command and runs specified scripts to version bump and publish. This would publish our packages keeping them in lockstep. There is value though, potentially, in having some packages increment versions with each other and be on the same version. If we do a patch on one package it doesn't necessarily make sense to publish a new patch version on everything in the repo. How shall we best deal with this?

Since we haven't been able to find anything completely built out, we are going to have to work our own. There is a package called changesets that is primarily built for use with JavaScript and Yarn. As mentioned before, we do have rust code in our library so we can't use changsets out of the box, but the bulk of the operations are done through a CLI and managed with markdown files. The package is something that, once we have initialized, can mostly run the CLI in our CI and doesn't need to be handled by the user. For a user to recommend a package change, they need only create a markdown file in the .changesets folder. While having the CLI create the file for you is nice, it isn't a necessity.

The version bump and polishing sequences are tightly coupled to JavaScript though. However, the implementation of changesets is split up nicely into packages each with their own scope. We could use the packages that parse the markdown files into version changes, and build a life cycle around it. It would run version bumps and publishes based on a script that we pass. There is nothing that is yet published, but experimentation has shown promising results. Regardless if the code changing is Rust or JavaScript, we can describe the change in markdown. This will parse the markdown for us and we can then issue commands based on the described version bump. After the version is bumped, we need only issue a publish command for crates or npm. Since we don't need dynamic use of this library, we could manually set each package to publish using a specified script.

The only sticky point is the changelog creation. It is rather coupled to code around the publishing sequence. We will need to rip out peices of that to keep that functionality.

Leveling Up Our Releases

We will look to do even more above and beyond the typical publish workflow in the later phases of our Github Actions use. This project has a deep consideration for security that is worth bringing to our publishing workflow. A workflow could involve publishing the package to multiple package managers including a private one hosted by Tauri. We can also do some interesting things like signing our releases, including a hash in the release and/or even publishing this information on a blockchain that it can be easily verified. Publishing on the blockchain is another avenue to increase the confidence that what is seen on GitHub matches what you have downloaded. The IOTA foundation created a Github Action which will publish a release to their blockchain. This has shown promise, but he gave a couple errors to tackle still.

Publish and Release Checklist

Let's wrap all of this into nice little bullet pointed list. (That's basically .yml right? You will soon be an expert at reading it if you aren't already :D ) This is the ideal that we are working towards. As it stands now, we have #3 through #6 implemented. We manually do #2 which then feeds into #3 and kicks off the rest of the automatic workflow.

a human pushes to dev through a pull request (can happen any number of times)
- pull request includes a changeset file describing the change and required version bump
a pull request is created (or updated) to include the change and version bump
- this pull request stays open and will be force pushed until it gets merged (and published)
- increase the version number based on changesets
- delete all changeset files
a codeowner merges the publish PR to dev (no direct push permissible for anyone)
- all tests (unit, e2e, smoke tests) are run on the PR
- failures prevent the publish so they must pass before merge
merge to dev triggers release sequence
- changes are squashed and a PR is opened against master
when PR to master is merged...
- vulnerability audit (crates and yarn) and output saved
- checksums and metadata and output saved
- packages are published on npm/cargo, tarball/zip created
- release is created for each package that had updates (if version isn't changed, build skips the publish steps)
- output from audit/checksums is piped into the release body
- tarball / zip attached to release
- async process to publish to IOTA tangle (feeless) via release tag [note: still have things to resolve here]
release is complete
- master has updated code and tagged
- GitHub release has tarballs, checksums, and changelog (may have multiple releases if more than one package published) [note: is part of step 2 and is not yet implemented]

Hopefully this inspires you to implement this into your own workflows. If you have any questions, feel free to reach out and I would be happy to answer. Cheers!

Use Sass Variables in Javascript

Daniel Thompson-Yvetot — Sat, 01 Feb 2020 13:41:09 +0000

Sass variables are awesome in that they guarantee that you are using the right colors, dimensions, animations etc. everywhere in your Webapp. It is, unfortunately, not very straightforward to access them in Javascript - and using them from Tauri is an exercise in mind-bending futility.

This is a little writeup about a nice and easy solution for accessing Sass variables in your Javascript.

For this tutorial, we are going to assume you already have Sass working in your project. We're going to be using the VueJS based Quasar Framework, but the same principle should work with other frameworks as well.

1) Add the dependency

We don't need to ship this, as we are going to be using it only at build time.

yarn add --dev node-sass-json-importer

2) Update your webpack config

Quasar has a special build setting in quasar.conf.js that you can easily modify:

const jsonImporter = require('node-sass-json-importer')
module.exports = function (ctx) {
  return {
    ...
    build: {
      ...
      sassLoaderOptions: {
        sassOptions: {
          importer: jsonImporter()
        }
      }
    }
  }
}

3) Create your variables

You can save your settings as JSON in src/css/quasar.variables.json. Of course you can add whatever you want here, just be sure not to repeat these keyValues in your real SASS file.

{
    "primary": "#3215B3",
    "secondary": "#29269A",
    "accent": "#9C27FF",
    "info": "#3100EC",
    "spotColor" "#C0FF33"
}

4) Update your SASS file:

Replace your src/css/quasar.variables.sass with the following:

@import "./quasar.variables.json"

5) Create and register a bootfile `src/boot/sass.js`

With quasar you can put this in a bootfile.

import sass from '../css/quasar.variables.json'

export default ({ Vue }) => {
  Vue.prototype.$sass = sass
}

export { sass } // in case you need it outside of vue

Don't forget to register the bootfile in your quasar.conf.js!

6) Use your sass variable in a Vue SFC:

Of course this is just one thing you can do, the approach will work for any number of other things.

  methods: {
    sassColor (colorName) {
      return this.$sass[colorName]
    },
    sassSpotColor () {
      return this.$sass['spotColor']
    }
  }

7) Relax!

Image from Unsplash: https://unsplash.com/photos/M6lu8Wa72HQ

Publish to NPM with Github Actions

Daniel Thompson-Yvetot — Sat, 25 Jan 2020 14:44:47 +0000

If you are as addicted to CI and CD as we are at Tauri, this brief article will show you how we solved publishing to NPM on the release tag event at Github.

Background

Our org is growing, and we don't want individuals to bear the responsibility for publishing to crates.io and npm. That's brittle and bus-factor waiting to happen. And doing things manually is always error prone.

What we did:

Setup a CI user at NPM (don't choose 2FA), and copy their token.
Create a secret at the repo settings, call it npm_token and paste the token as the secret value.
Create a file at .github/workflows/publish.ymlwith the following contents:

name: NPM Publish

on:
  release:
    types: [published]

jobs:
  publish:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v2
    - name: Use Node 12
      uses: actions/setup-node@v1
      with:
        # specify node version and the registry for the RELEASE build
        node-version: 12
        registry-url: https://registry.npmjs.org/
    - name: Build package
      run: |
        npm install -g yarn
        yarn install
        yarn rollup -c
    - name: Register Token
      run: |
        echo "//registry.npmjs.org/:_authToken=$NODE_AUTH_TOKEN" > /home/runner/work/_temp/.npmrc
        echo "_auth=$NODE_AUTH_TOKEN" >>  /home/runner/work/_temp/.npmrc
        echo "email=<your@email.address>" >>  /home/runner/work/_temp/.npmrc
        echo "always-auth=true" >>  /home/runner/work/_temp/.npmrc
      env:
        NODE_AUTH_TOKEN: ${{ secrets.npm_token }}
    - name: Publish
      run: npm publish

Now just publish a release and let the runner do its thing.

Let us know in the comments if you've got any improvements!

https://github.com/features/actions
https://github.com/tauri-apps/tauri-forage (the repo where we're using this)
Image from Unsplash: https://unsplash.com/photos/Tzm3Oyu_6sk

tauri.studio

Daniel Thompson-Yvetot — Mon, 06 Jan 2020 11:07:35 +0000

We're happy to announce that we launched the website for tauri, which you can find here:

https://tauri.studio

You'll find an introduction about how Tauri has been designed to let you use your current web framework to make tiny and really secure apps - and you don't even have to know rust to profit from it.

https://tauri.studio/en/patterns

We've also included some comparisons between common patterns that you can use to build your apps, like my personal favourite, the Kamikaze pattern:

https://tauri.studio/en/security

There is also a pretty thorough writeup of our security posture and some of the things we've got in the pipeline.

Documentation

For the time being, we are hosting our docs as a GitHub wiki, so if you just want to dive in, please check it out here:

https://github.com/tauri-apps/tauri/wiki

Tauri is an MIT licensed FLOSS project that you can contribute to!

Join a working group at Discord
Make a donation via Github sponsors or opencollective
Just try it out and give us your feedback

Branding and Rebranding

Daniel Thompson-Yvetot — Sat, 14 Sep 2019 11:45:49 +0000

Tauri has had a few facelifts, but we think we nailed it this time.

Proton

The first name for Tauri was Proton, because we wanted to pick a fight with Electron. (We don't anymore, btw. Electron is still super awesome!)

At the time we were incubated at the Quasar Framework, so it made sense to riff off of the Quasar logo. This is what we had:

So as (bad) luck would have it, every single particle from physics already had a javascript project associated with it, and to our dismay it turned out that Proton-Native was also a thing.

Quasar-Tauri

So we spent about a week discussing a new name, and came up with Tauri, named after the Binary Star type.

This made sense because of the way we were planning to build Tauri apps. So we removed one of the sub-particles from the Proton logo and ended up with this nice little guy.

One of the comments from the community was that it was cool how the logo seemed to riff off of the Gear from Rust. This was totally unintentional though, because Quasar's logo is for a pure JS project, and the "gear" is more of a stylized vortex.

Post Quasar

At any rate, after we left the incubator to spin up our own organization, we had to make another logo because we couldn't justify using the former design basis. One of the early ideas was to make a logo with more "bite", so I put together an example using a real gearset that I prototyped over at https://geargenerator.com - and the author Abel Vincze even comped us a download. (Fun fact: the Rust logo has the same number of teeth as both healthy adult humans and giraffes: 32.)

But the two inner gears just made it seem too aggressive, and then a third gear was added:

But it all just seemed a bit off. So, after about a week of discussion and some deep thinking about the name Tauri, we ended up with a graphic stylization of Theta Tauri, a real binary star whose abbreviation is θ Tau.

What I loved about that is that the theta symbol could be an impulse for the design, so I found an image of Theta-Tauri in the Hyades Cluster, and after a bit of back and forth in the Working Group for Media, we ended up with this, our latest design:

Takeaways

Coming up with a design is hard work. Redesigning things seems to take more time, especially when there are a lot of stakeholders. But its still a valuable exercise in team communication and transparency.

Get in Touch

Tauri apps aren't quite ready for prime-time and there is a lot of work needed in the codebase and the governance structure to get to that point. Nevertheless, in our quest for transparency and community involvement, we are taking this opportunity to invite everyone from the Rust, Appsec and Dev communities to come around and find out where the project is at, where it is going and how to get involved in the working groups.

Tauri is an organization that seeks to follow the best practices of the SFOSC principles. It is our duty and pleasure to humbly invite you to visit our public GitHub project page, hang out at our Discord chat server, donate money at our Open Collective page or simply follow our Tweets.

About the Author

Daniel Thompson-Yvetot is the principal architect and security engineer behind Tauri. He has been an open source evangelist for the last 13 years and is an active member of the Sustainable Free and Open Source Communities (SFOSC).

We want smaller, faster, more secure native apps

Daniel Thompson-Yvetot — Thu, 05 Sep 2019 20:58:38 +0000

The Situation Room

In 2019, the manufacture of native-apps from compile-to-javascript user-interface frameworks has become easier and more accessible than ever before. All the same, beginners and seasoned developers alike are confronted with tough choices in a rapidly changing landscape of security and privacy. This is especially true in the semi-trusted environment of user devices, where vendors fragment the already diverse ecosystem with their proprietary "solutions".

The fragmentation of the app landscape doesn't end with devices though, as there are not only innumerable front-end frameworks like React, Angular, Vue and Svelte ... but also a range of packagers like Capacitor, Electron, Proton-Native and others popping up daily. Multiply this with insecure dependency management and incomplete vulnerability remediation, and we are left with a fractured ecosystem where the winners are merely the lucky ones who haven't gotten hit - yet.

The fact is that most of these frameworks were never conceived to exist outside of the browser sandbox and have been suddenly thrust into a very hostile environment where development teams resort to applying workarounds like shipping shared certs, hacking on-device registries or stooping to the unfortunately common integration of localhost servers on the devices themselves.

A Paradigm Shift

Tauri approaches these issues head on, as it was designed from the ground up to embrace novel patterns for secure development and creative flexibility that leverage the language features of Rust and enable you to grow your app using any front-end framework you like. And all of that in a much more secure distribution environment.

With Tauri as a component in your toolchain, you will be able to design, build, audit and deploy tiny, fast, robust and secure native applications for the major Desktop and Mobile platforms in record time. You can do all this within your preferred dev environment, using any framework and without even needing to know the Rust programming language. If you know Rust, however, you will be empowered to make even more amazing integrations with the underlying operating system and hardware.

The Tauri-Team has already completed some initial proofs of concept using WebViews (with really encouraging results such as < 3MB binaries on MacOS, Windows and Linux). At the moment we are finalizing the API, preparing smoke-tests, investigating cross-compilation tools and even building a binary evaluation harness. However, we are not totally satisfied with the WebView approach, and are investigating alternatives like Servo and Webkit.

DEV Community: Tauri

Tauri 1.0 Release Candidate

Our Working Method

Progress

Usability

Documentation

Security Features

Next Steps

Sustaining Community

TAURI FEATURE FREEZE AND SECURITY AUDIT

Announcing Tauri Beta - More efficient crossplatform apps with better features

So, what Is Tauri?

What's New?

WRY (Webview Rendering librarY)

TAO

Rust CLI

cargo run Support

New Web Content Loader

Multiwindow

Improved Command Handling

Updater

External Audit

Get Started With Tauri

What Tauri does not

Who is Tauri

What's Next?

Use deno to build a Tauri App

Rig and build!

Benchmarking

deno

command

with antibloat

no antibloat

no antibloat, just .app

node.js

command

with antibloat

no antibloat

no antibloat, just .app

Discussion

Setting Up CI and CD for Tauri

Setting Up CI/CD for Tauri

Background

Next Phase of Testing

Our Examples (aka Smoke Tests)

Next Level Publishing

Leveling Up Our Releases

Publish and Release Checklist

Use Sass Variables in Javascript

1) Add the dependency

2) Update your webpack config

3) Create your variables

4) Update your SASS file:

5) Create and register a bootfile src/boot/sass.js

6) Use your sass variable in a Vue SFC:

7) Relax!

Publish to NPM with Github Actions

Background

What we did:

tauri.studio

https://tauri.studio

https://tauri.studio/en/patterns

https://tauri.studio/en/security

Documentation

Branding and Rebranding

Proton

Quasar-Tauri

Post Quasar

Takeaways

Get in Touch

About the Author

We want smaller, faster, more secure native apps

The Situation Room

A Paradigm Shift

Get in Touch

About the Author

`cargo run` Support

5) Create and register a bootfile `src/boot/sass.js`