# mutex_m migration

RBS gem has bundled type definition under `stdlib/mutex_m`. Since the type definition of the library is stable enough, we move the type definition under the gem itself.

The migration path is defined based on the source of the dependencies:

1. Bundler context
2. `gems:` field in `rbs_collection.yaml`
* with `source: { type: stdlib }`
* without `source:` attribute
3. `dependencies:` field in `manifest.yaml`

## Bundler context

This means the gem is included in the bundler context, explicitly in `Gemfile`, or as a indirect dependency.

1. If the version of the `mutex_m` gem has `sig` directory (>= 0.3.0), rbs will use the type signature from the gem.
2. If the version of the `mutex_m` gem doesn't have `sig` directory, rbs will emit a warning and use the stdlib version.

## `gems:` attribute in collection config

I don't know how this can happen, but the attribute can be used for this.

1. If `source:` attribute is given and points to `stdlib`, rbs will emit a warning to migrate to the gem, and load it from stdlib, not a gem.
2. If `source:` is not given, it loads RBS from the gem.

## `dependencies:` field in `manifest.yaml`

Usually, the `dependencies:` are stdlib. But for the smoother migration, `mutex_m` (and other *alumni* stdlibs) will be loaded through the dependencies.

* If `mutex_m` is not included in the Bundler context, rbs will use the stdlib type definition, and emit a warning to add `mutex_m` to the Bundler.
* If `mutex_m` is included in the Bundler context, rbs will use the gem-bundled type definition, and emit a INFO warning to remove it from `dependencies:` of `manifest.yaml`.