Jake Wharton

Are you using `===` on purpose? Whether or not the "to" functions return the original instance or not is an implementation detail, not something that should be relied upon. >...

If you're inside a monospace span (single backtick delimited) you might want two spaces preserved.

Note that `.plus(2)` is not actually a statement. The expression body code should not kick in for what you wrote, though.

Regular line breaks within a statement will indent subsequent lines. So `addStatement("return 1\n.plus(2)")` should work.

I agree that JS is valuable. I also agree that we need to do this piece by piece. The TypeName hierarchy seems like a good candidate.

I don't think this PR is reviewable. We need to start with something smaller in scope like the TypeName hierarchy by itself. There's way too much API surface here to...

I definitely mentioned only doing something small like TypeName first _somewhere_, but I can't find where. It's too hard to judge whether this is correct or not since it's so...

Since we have no users on other targets, we can expect/actual odd dependencies and use `TODO()` implementations for now.

Can you write an integration test? In general we prefer to test against the public API and generated code so that we can ensure we cover the cases that consumers...

If your change doesn't affect imports you can write tests for the `TypeAliasSpec` in here: https://github.com/square/kotlinpoet/blob/d2090c3bb2f9935cbbef3d2bcc1b092b15558bc1/kotlinpoet/src/commonTest/kotlin/com/squareup/kotlinpoet/TypeAliasSpecTest.kt#L34 If it does affect imports, add a test to `FileSpecTest`: https://github.com/square/kotlinpoet/blob/d2090c3bb2f9935cbbef3d2bcc1b092b15558bc1/kotlinpoet/src/commonTest/kotlin/com/squareup/kotlinpoet/FileSpecTest.kt#L912-L937