munificent

Spent a bunch of time talking to Nathan, Siggy, and Kevin about how to handle pub serve with stuff outside of web/. Our goals are:

1. Root-relative URLs inside web/, test/, example/, and even things like subdirectories of example/ should be supported. This means that the root directory being served needs to be constrained to those.

   We can't require the user to hit localhost:8080/example/example1/foo.html because it would break a root-relative URL in foo.html.

2. More than one of these directories needs to be servable simultaneously. If you have to shut down the server and restart it (which entails rebuilding

adam-singer

#!/usr/bin/env bash

set +o xtrace
USER=$USER
PROJECT=dart-compute-project
INSTANCE_NAME=dart-compute
TAGS=dart
MACHINE_TYPE=f1-micro
NETWORK=default
IP=ephemeral

azenla

Accepted

• Generalized Tear Offs
• Null-Aware Operators

Drafts

• Configured Imports
• Parameterized Libraries
• Combined Named and Position Optional Parameters

FaisalAbid

FROM google/dart

WORKDIR /app

ADD pubspec.* /app/
RUN pub get
ADD . /app
RUN pub get --offline

CMD []

kevmoo

#!/usr/bin/env dart
import 'dart:async';
import 'dart:convert';
import 'dart:io';

const _splitter = const LineSplitter();

const _waitDuration = const Duration(milliseconds: 250);

const _green = '\u001b[32m';

munificent

Pub has two commands for working with transformers, build and serve. Both of those currently are hardcoded to only see stuff in your package's web/, asset/, and lib/ directories. We've been wanting to have support for test/, example, and others for a while (see #14673 and #15924). This sketches out what I'm thinking to handle this. Feedback is welcome!

The basic idea is that build and serve will be able to see of these directories: asset/, benchmark/, bin/, example/, test/, and web/. Transformers will be able to run on assets in any of those.

The build/ directory

Right now, pub build creates a build/ directory containing the output of the build process. That directory only contains the outputs whose path is within web/. If we start building tests and examples into there, stuff could start colliding.

So the first change is that we'll reorganize the build/ directory to match your package. Outputs within web/ will

jelbourn

// Overlays one color on top of another and returns the resulting color.
// This is used to determine contrast ratio for two colors with partial opacity.
// See http://en.wikipedia.org/wiki/Alpha_compositing#Alpha_blending
@function alpha-blend($overlay, $base) {
  $overlayAlpha: alpha($overlay);
  $baseAlpha: alpha($base);

  // If the overlaid color is completely opaque, then the result is just going to be that color.
  @if $overlayAlpha >= 1 {
    @return $overlay;

slightfoot

import 'package:flutter/material.dart';
import 'package:flutter/rendering.dart';

void main() => runApp(TestApp());

enum TestId {
  First,
  Second,
  Third,
}

kevmoo

# Inspired by https://robots.thoughtbot.com/use-git-hooks-to-automate-annoying-tasks

dart_files=$(git diff --cached --name-only --diff-filter=ACM | grep '.dart$')

[ -z "$dart_files" ] && exit 0

function checkfmt() {
  unformatted=$(dartfmt -n $dart_files)
  [ -z "$unformatted" ] && return 0

azenla

/// Dart is built around a timer, which basically schedules functions in a queue.
/// The Future class is essentially just sugar on top of the event loop.
/// To help people understand what the event loop actually does, I have written code which implements the event loop.
/// See https://www.dartlang.org/articles/event-loop/ for more information.

import "dart:async";

class EventLoop {
  /// Function Queue.
  static final List<Function> queue = [];