Ecosyste.ms: Awesome

An open API service indexing awesome lists of open source software.

https://github.com/Workiva/over_react_codemod

Codemods to help consumers of over_react automate the migration of UI component code.
https://github.com/Workiva/over_react_codemod

Last synced: 11 days ago
JSON representation

Codemods to help consumers of over_react automate the migration of UI component code.

Lists

README

        

# Over React Codemods

[![Pub](https://img.shields.io/pub/v/over_react_codemod.svg)](https://pub.dartlang.org/packages/over_react_codemod)
[![Build Status](https://github.com/Workiva/over_react_codemod/workflows/Dart%20CI/badge.svg?branch=master)](https://github.com/Workiva/over_react_codemod/actions?query=workflow%3A%22Dart+CI%22+branch%3Amaster)

> **Built with [dart_codemod][dart_codemod].**

Codemods to help consumers of [over_react][over_react] automate the migration of
UI component code.

## Installation

> Note: this package requires Dart SDK version 2.1.0 to run, but the codemods
> themselves are designed to run on code that is written for Dart 1.x or 2.x.

```bash
dart pub global activate over_react_codemod
```

Once you've activated this package, you should be able to run whichever codemods
you need via `pub global run`.

## Internationalization Codemod

This package provides a `intl_message_migration` codemod that will modify existing UI component code to make them available for internationalization.

For more information, please see the [INTL Message Codemod Readme](docs/intl_message.md)

## Dart 1 to Dart 2 Codemod

This package provides a `dart2_upgrade` codemod that will modify existing
over_react component code to be compatible with Dart 2 and the over_react
builder.

Depending on your needs, you may be able to upgrade directly from Dart 1 to
Dart 2, or you may need to take an intermediary step and provide a version of
your codebase that is both forwards- and backwards-compatible. Both of these
options are supported by this codemod.

- `dart pub global run over_react_codemod:dart2_upgrade --backwards-compat`

Use this codemod to migrate your over_react code to a format that is both
forwards-compatible with Dart 2 and backwards-compatible with Dart 1.

- `dart pub global run over_react_codemod:dart2_upgrade`

Use this codemod if you want to migrate to Dart 2 compatible code and do not
need to maintain backwards-compatability with Dart 1. You can run this to
immediately upgrade from Dart 1 to Dart 2, or you can run this on code that
has already been run through this codemod with the `--backwards-compat`
flag once you're ready to drop Dart 1 support.

For more information on the transition from Dart 1 to Dart 2 and how it affects
over_react, check out the [over_react Dart 2 migration guide][over_react_dart2].
It includes sample diffs of the changes that these codemods will introduce.

## Checking for Regressions

Especially in the case where a forwards- and backwards-compatible version of
your code is necessary, it can be helpful to be able to check automatically for
regressions after having initially migrated your code. Doing so will help
prevent accidentally merging code that doesn't meet your compatability
expectations.

Each of these codemods can be run in a `--fail-on-changes` mode that will count
the number of changes that _would_ have been suggested and exit with a non-zero
exit code if that number is greater than 0.

As an example, adding the following command to your CI process or pre-merge
checklist will prevent merging code that is not in the form that is compatible
with both Dart 1 and Dart 2:

```bash
dart pub global run over_react_codemod:dart2_upgrade --fail-on-changes
```

## Ignoring Codemod Suggestions

Some of the changes provided by the codemods in this package are based on
imperfect heuristics (e.g. looking for a specific naming convention) and
consequently may be susceptible to false positives. If you hit such a case in
your codebase, you can tell the codemod to ignore a certain line by attaching an
ignore comment either on the same line or the immediately preceding line.

For example, consider a mixin usage that happens to match the naming convention
of ending with `StateMixin`, but isn't actually an over_react state mixin:

```dart
class Foo extends Object with BarStateMixin {}
```

As is, the `dart2_upgrade --backwards-compat` codemod would find this code and
attempt to change it to:

```dart
class Foo extends Object
with
BarStateMixin,
// ignore: mixin_of_non_class, undefined_class
$BarStateMixin {}
```

But if `BarStateMixin` isn't actually an over_react state mixin, then this
updated code will fail. To avoid this problem, simply add an `// orcm_ignore`
comment to the mixin type that should be ignored:

```dart
class Foo extends Object
with
// orcm_ignore
BarStateMixin {}
```

This ignore mechanism works with any of the changes that the codemods in this
package will try to suggest.

## Authoring codemods

### Resources

- Analyzer package
- [AST documentation](https://github.com/dart-lang/sdk/blob/master/pkg/analyzer/doc/tutorial/ast.md)
- [Element model documentation](https://github.com/dart-lang/sdk/blob/master/pkg/analyzer/doc/tutorial/element.md)
- (the element model is only accessible from "resolved AST")
- In general, the various `AstNode` and `Element` subclasses are well-documented, and are very helpful in describing the relationships between different types of nodes/elements and pointing to other classes. Reading those and clicking through the references is a good way to learn about specific structures, and help get your bearings.
- [codemod][dart_codemod] package

### Best practices

- Code defensively for edge-cases, and avoid assumptions about the AST or Element model.

Some codemods process a lot of code, especially when identifying code that should be operated on, and some of that code may have structures you don't expect.

That doesn't necessarily mean your codemod should handle every single edge-case, but generally it shouldn't break with uncaught exceptions when it encounters certain code.

Things to avoid assumptions about:

- The types or nullability of child/parent nodes
- Prefer type checks over casts
- `tryCast()` and `ancestorOfType()` can be handy in certain cases.
- Prefer null-checks over `!`
- The number of child nodes or other items in collections
- When using `.first`/`.last`/`.single` on iterables, either check the length of the iterable first, or switch to something more conditional like `.firstWhere()` or `.firstOrNull`

- Avoid using `childEntities`

Most AST node classes have getters for their different child nodes. Using these helps make code easier to read, and also provide typing (and nullability) which helps with static analysis and autocomplete.

If you're manually traversing the AST trying to find a certain descendant, consider whether a visitor-based implementation would be better.

- Avoid using `AstNode.toSource()` (or `.toString()`) outside of tests

- To identify relevant code. There may be different syntax variations (either current or in future Dart versions) of code that unintentionally wouldn't be a match.

For example, if we were doing `expression.toSource() == 'foo.bar()'`, we would miss the following cases:
```dart
foo..bar();
foo?.bar();
namespaced_import.foo.bar();
foo.bar(optionalArgAddedInSubclass: true);
```

Instead, we could check for the method name via:
```dart
expression is MethodInvocation && expression.methodName.name == 'bar'
```
and change the foo check to something else, depending on the use-case:
```dart
// Check whether the target is a "foo" identifier
// (though this doesn't handle prefixed cases)
expression.realTarget?.tryCast()?.name == 'foo'
// Check whether it statically points to a `foo` variable
expression.realTarget?.tryCast()?.staticElement?.name == 'foo');
// Or, Check whether it's a `Foo` object:
isFooType(expression.realTarget?.staticType);
// (Or, something else)
```

For cases where the syntax seems simple enough where variations shouldn't be a problem, there are usually APIs that provide the value you're looking for.

```dart
final identifier = parseIdentifier('foo');
identifier.name; // 'foo'

final boolean = parseBooleanLiteral('false');
boolean.value; // false

final import = parseImportDirective('import "package:foo/foo.dart";');
import.uriContent; // 'package:foo/foo.dart'
```

- For building patch strings (such as when moving code from one place to another).

`toSource()` provides an approximation of the source, and may be missing comments or have different whitespace. If needed, use the `context.sourceFile` to get the original source for a given node.

- Don't make assumptions about existing whitespace and line breaks.

There are different ways code can be formatted with dartfmt, and some code may not be formatted at all, so it's unsafe to make assumptions.

For instance, if you'd like to yield a patch that deletes a newline with some code, either check for its existence first by getting the source or line number of that offset in `context.sourceFile`. Or, instead of deleting from `node.offset`, delete from the end of the previous token (`node.prevToken?.end ?? node.offset`) to take any whitespace between those nodes with it.

[dart_codemod]: https://github.com/Workiva/dart_codemod
[over_react]: https://github.com/Workiva/over_react
[over_react_dart2]: https://github.com/Workiva/over_react/blob/master/doc/dart2_migration.md