docs: replace asides with hints or warnings

Author: chriskrycho

docs/cookbook/overview.md

@@ -2,12 +2,12 @@
 
 This “cookbook” section contains recipes for various scenarios you may encounter while working on your app or addon.
 
-<aside>
+{% hint style="info" %}
 
 Have an idea for an item that should fit here? [Open an issue for it!][gh-issue] We'd love to help you help us make this experience more awesome for everyone.
 
 [gh-issue]: https://github.com/typed-ember/ember-cli-typescript/issues/new/choose
 
-</aside>
+{% endhint %}
 
 - <LinkTo @route='docs.cookbook.working-with-route-models'>Working with route models</LinkTo>

docs/ember/components.md

@@ -1,11 +1,10 @@
 # Components
 
-<aside>
+{% hint style="info" %}
 
 New to Ember or the Octane edition specifically? You may want to read [the Ember Guides’ material on `Component`s](https://guides.emberjs.com/release/components/) first!
 
-</aside>
-
+{% endhint %}
 
 Glimmer Components are defined in one of three ways: with templates only, with a template and a backing class, or with only a backing class (i.e. a `yield`-only component). When using a backing class, you get a first-class experience using TypeScript! Unfortunately, we don’t yet support type-checking for templates, but we hope to build that out eventually. Don’t let that stop you, though: types in your component classes make for a great experience, so let’s dig in and see how it works in practice.
 
@@ -84,11 +83,11 @@ The types for `owner` here and `args` line up with what the `constructor` for Gl
 
 If we used `object`, we could end up with TypeScript thinking `args` were an array, or a `Set`, or anything else that isn’t a primitive. Since we have `{}`, we *know* that it's an object.
 
-<aside>
+{% hint style="info" %}
 
 For some further details, check out [this blog post](https://mariusschulz.com/blog/the-object-type-in-typescript).
 
-</aside>
+{% endhint %}
 
 The `args` passed to a Glimmer Component [are available on `this`](https://github.com/glimmerjs/glimmer.js/blob/2f840309f013898289af605abffe7aee7acc6ed5/packages/%40glimmer/component/src/component.ts#L12), so we could change our definition to return the names of the arguments from a getter:
 

docs/ember/helpers.md

@@ -2,14 +2,15 @@
 
 Helpers in Ember are just functions or classes with a well-defined interface, which means they largely Just Work™ with TypeScript. However, there are a couple things you’ll want to watch out for.
 
-<aside>
+{% hint style="info" %}
 
 As always, you should start by reading and understanding the [Ember Guide on Helpers][guide]!
 
-</aside>
-
 [guide]: https://guides.emberjs.com/release/templates/writing-helpers/
 
+{% endhint %}
+
+
 ## Function-based helpers
 
 The basic type of a helper function in Ember is:

docs/ember/services.md

@@ -2,14 +2,14 @@
 
 Ember Services are global singleton classes that can be made available to different parts of an Ember application via dependency injection. Due to their global, shared nature, writing services in TypeScript gives you a build-time-enforcable API for some of the most central parts of your application.
 
-<aside>
+{% hint style="info" %}
 
 If you are not familiar with Services in Ember, first make sure you have read and understood the [Ember Guide on Services][guide]!
 
-</aside>
-
 [guide]: https://guides.emberjs.com/release/services/
 
+{% endhint %}
+
 ## A basic service
 
 Let's take this example from the [Ember Guide][guide]:

docs/ember/testing.md

@@ -12,13 +12,13 @@ One major difference when working with TypeScript in *app* code is that once you
 
 First, the function we're testing might look like this.
 
-<aside>
+{% hint style="info" %}
 
 Here we’re using the `assert` from `@ember/debug`. If you’re not familiar with it, you might want to take a look at its [API docs][debug-assert]! It’s a development-and-test-only helper that gets stripped from production builds, and is very helpful for this kind of thing!
 
 [debug-assert]: https://api.emberjs.com/ember/3.14/functions/@ember%2Fdebug/assert
 
-</aside>
+{% endhint %}
 
 ```js
 // app/utils/math.js
@@ -212,13 +212,13 @@ export default class Profile extends Component<User> {
 }
 ```
 
-<aside>
+{% hint style="info" %}
 
 Not familiar with how we define a Glimmer `Component` and its arguments? Check out [our guide][glimmer-component]!
 
 [glimmer-component]: ./components/
 
-</aside>
+{% endhint %}
 
 Now, with that setup out of the way, let’s get back to talking about the text context! We need to set up a `User` to pass into the test. With TypeScript on our side, we can even make sure that it actually matches up to the type we want to use!
 
@@ -343,10 +343,10 @@ module('Integration | Component | Profile', function(hooks) {
 
 Now everything type-checks again, and we get the nice auto-completion we’re used to when dealing with `this.user` in the test body.
 
-<aside>
+{% hint style="info" %}
 
 If you’ve been around TypeScript a little, and you look up the type of the `TestContext` and realize its an interface, you might be tempted to reach for declaration merging here. Don’t! If you do that, *every single test in your entire application* will now have a `user: User` property on it!
 
-</aside>
+{% endhint %}
 
 There are still a couple things to be careful about here, however. First, we didn’t specify that the `this.user` property was *optional*. That means that TypeScript won’t complain if you do `this.user` *before* assigning to it. Second, every test in our module gets the same `Context`. Depending on what you’re doing, that may be fine, but you may end up needing to define multiple distinct test context extensions. If you *do* end up needing to define a bunch of different test context extension, that may be a sign that this particular set of tests is doing too much. That in turn is probably a sign that this particular *component* is doing too much!

docs/index.md

@@ -2,11 +2,11 @@
 
 This guide is designed to help you get up and running with TypeScript in an Ember app.
 
-<aside>
+{% hint style="warning" %}
 
 **This is *not* an introduction to TypeScript *or* Ember. Throughout this guide, we’ll link back to [The TypeScript Docs](https://www.typescriptlang.org/docs/home.html) and [the Ember Guides](https://guides.emberjs.com/release/) when there are specific concepts that we will not explain here but which are important for understanding what we’re covering!**
 
-</aside>
+{% endhint %}
 
 To get started, check out the instructions in [Getting Started: Installation](./getting-started/installation)
 
@@ -16,8 +16,6 @@ To get started, check out the instructions in [Getting Started: Installation](./
 
 ## Why TypeScript?
 
-<aside>Just want to dive in? {{docs-link (html-safe 'Click here &rarr;') 'docs.index'}}</aside>
-
 What is TypeScript, and why should you adopt it?
 
 > TypeScript is a typed superset of JavaScript that compiles to plain JavaScript.  

docs/legacy/ember-object.md

@@ -12,11 +12,11 @@ When working with the legacy Ember object model, `EmberObject`, there are a numb
 
 Additionally, Ember’s mixin system is deeply linked to the semantics and implementation details of `EmberObject`, *and* it has the most caveats and limitations.
 
-<aside>
+{% hint style="info" %}
 
 In the future, some of these may be able to drop their `EmberObject` base class dependency, but that will not happen till at least the next major version of Ember, and these guides will be updated when that happens.
 
-</aside>
+{% endhint %}
 
 
 ## Mixins and classic class syntax
@@ -25,11 +25,11 @@ The Ember mixin system is the legacy Ember construct TypeScript supports *least*
 
 While we describe here how to use types with classic (mixin-based) classes insofar as they *do* work, there are many failure modes. As a result, we strongly recommend moving away from both classic classes and mixins, and as quickly as possible. This is the direction the Ember ecosystem as a whole is moving, but it is *especially* important for TypeScript users.
 
-<aside>
+{% hint style="info" %}
 
 The [Ember Atlas] includes guides for migrating [from classic classes to native classes][classic to native], along with [a variety of patterns][mixin patterns] for dealing with specific kinds of mixins in your codebase.
 
-</aside>
+{% endhint %}
 
 [Ember Atlas]: https://emberatlas.com
 [classic to native]: https://www.notion.so/Native-Classes-55bd67b580ca49f999660caf98aa1897