Dart News & Updates

Dart 1.14 is now available . This release contains a number of additions and improvements across our core libraries and our tools. Progress towards eliminating symbolic links Symbolic links for package resources can cause problems, especially on Windows. Since Dart 1.12, we’ve been working to support a Package Configuration File . The goal of this work is to provide a better model for package access. Dart 1.14 contains new APIs in both dart:io and dart:isolate to provide code access to the configuration file if it’s being used. You should consider these APIs experimental as we update the test package and pub to validate the implementation. Access package assets easily and reliably Developers frequently need to directly access assets within packages. In the past this has lead to confusion when supporting the many ways in which a Dart program can be executed. Along with the new Package Configuration APIs added in Dart 1.14, we’ve also released a resource package . This packa...

I often find myself working with a class of Dart packages I like to think of as core library expansion packs . They aren’t the splashiest, they don’t produce cool demos, but they’re extremely useful. These expansion packages, which are always named after a dart: library, build upon that library’s design and functionality to provide utility classes and fill in missing features. Actual core libraries—the things you get when you write import "dart:..." —are very useful because they’re always there, but they’re also really painful to change. Exactly because they’re always there, they have much stronger stability guarantees than the rest of the ecosystem. It’s dangerous to even add a new class because it might conflict with a user’s class name and break existing code. And forget about adding an instance method. What if someone was implementing that class as an interface? For those reasons, the core libraries are kept as slim as possible. So what happens when we want to add a ...

Editor's note: This is the first post in a new series by Natalie going in-depth on Dart packages and how they're used. If you’ve written any Dart code at all, you’ve definitely used tools that use the stack_trace package . It was originally written for use in pub, and the test package uses it for all the stack traces that tests generate. But you don’t just have to rely on other tools to use it for you—you can use it yourself! The package has three main use-cases, all of which are important and useful. Originally, it was just designed to make existing stack traces prettier and easier to read. A big part of that was parsing stack traces into a data structure, so its secondary purpose became programmatically manipulating stack traces. Then once zones were created, it added support for tracking stacks across asynchronous calls. Making Traces Pretty Let’s face it: the Dart VM’s built-in stack traces aren’t nice to look at, and they don’t present information in a way that’...