Internals Refactor

[wagenet]

This consolidates a lot of stuff from @ember/-internals into its relevant packages. Not only is this better organizationally, but it puts us in a better place for correctly building type exports as it reduces the number of potential import locations for the same types.

[wagenet]

We re-export here since there are tests that want this to exist in @ember/-internals. These should be revisited in the future.

[wagenet]

We re-export here since there are tests that want this to exist in @ember/-internals. These should be revisited in the future.

[chriskrycho]

@wagenet looking at these two comments—can you open an issue tracking it? Maybe an issue tracking both big and small work to be done for getting us to a point where we can publish individual packages (including for types), and just adding items to the list as we discover them until they're done? Or possibly a project doing the same?

[sandstrom]

Out of curiosity, is there anything holding this PR back? Seems like a lot of good stuff!

[wagenet]

@sandstrom, just waiting on proper review!

[sandstrom]

@wagenet Alright, great! 😄

[chriskrycho]

I noted a bunch of places where our @module declarations in the docs seem to have been simply wrong, and AFAICT this is one part of why the actual generated module docs are substantially less useful than might have been hoped. Between your reorganization and adding those in, I think it might make a nice win for the docs while we're still on YUIDoc (though a colleague is working on doing the work to transition us to TSDoc-powered docs, almost certainly via TypeDoc). That said… it’s possible these are intentionally only showing the top-level module, which while deeply unhelpful may be important for some other reason at the moment?

cc. @jenweber @locks: do we want to have only (for example) @ember/routing rather than @ember/routing/route for the @module declarations?

---

A related thought: we should consider whether we might want to introduce a public/private directory, so that you end up with this for input/output structure:

.
├── dist
│   ├── -private
│   │   ├── internal-only.d.ts
│   │   └── internal-only.js
│   └── public
│       ├── index.d.ts
│       ├── index.js
│       ├── other.d.ts
│       └── other.js
└── src
    ├── -private
    │   └── internal-only.ts
    └── public
        ├── index.ts
        └── other.ts

Once this Typedoc issue is resolved, we can theoretically start leveraging package exports maps to make it so consumers cannot use the -private directories (if we so desire), with a very straightforward per-package config:

{
  "exports": {
    ".": "./dist/public/index.js",
    "./package.json": "./package.json",
    "./*": "./dist/public/*.js"
  }
}

[chriskrycho]

Probably for a follow-on and/or just needs clarification: is this because we monkey-patch it or similar silliness, such that we cannot use the 'rsvp' import?

[wagenet]

We've got extra stuff in @ember/-internals/runtime/lib/ext/rsvp.ts. Might still be fine to import from RSVP directly here though.

[chriskrycho]

One more tweak, not a blocker!

[chriskrycho]

Let's do it! …maybe starting by fixing CI? 😂