matan.dart

The personal Dart package of github.com/matanlurey.

This package contains code and configuration that I find myself wanting whenever working with Dart, but I don't want to bother publishing a more proper set of packages. If anything in this package grows too much in scope, it's a candidate for another package.

This package will never contain any non-dev depdencies.

Installation

Once upon a time the package manager was just pub, and I didn't have to add instructions.

dart pub add matan

Or when writing a Flutter app or package:

flutter pub add matan

If you only use strict.yaml, depend on this package as a dev dependency:

dart pub add matan --dev

Versioning

This package follows strict semantic versioning:

1. The MAJOR version is updated on any incompatible API change or lint change
2. The MINOR version is updated when functionality is added
3. The PATCH version is updated when bug fixes are made

However, if strict.yaml adds a new lint or modifies a setting that issues an informational message (not warnings or errors), it is considered a minor update. If your build will fail on additional info diagnostic messages it is recommended not to use strict.yaml.

Usage

See pub.dev/documentation/matan/latest/.

Unless otherwise specified, this package is intended to be an implementation detail; in other words, try not to return types declared in Dart libraries as part of your external/public API of your own package:

library my.library;

import 'package:matan/example.dart' show Example;

// BAD: Apps/packages that use your package are tighly bound on this package.
Example myFunction() => Example();

library my.library;

import 'package:matan/example.dart' show Example;

// GOOD: Dependencies of your package won't need to import this package.
YourOwnThing myFuncion() => YourOwnThing();

class YourOwnThing {
  // Keep this private, if it was public then again the type would leak out.
  final _delegate = Example();
}

Linting

In your analysis_options.yaml file, include:

include: package:matan/strict.yaml

I use the following rules when assigning severities:

• info: Provides stylistic consistentcy or avoids possible mistakes.
• warning: Makes your public API or implementaton safer; rare ignores are OK.
• error: This should never appear in your code and do not ignore it.

Of course, it's subjective not objective. Feel free to send a pull request.