[WIP] unsafe path methods

[dwickern]

I threw together a proof of concept from our discussion today. Any path related APIs accept a keyof now, and you can opt into an unsafe version which takes a string.

I'm not sure how we would deploy something like this.

[chriskrycho]

I think the best way to deploy it would probably be as an optional dependency. We could (a) create a standalone package for it (like ember-unsafe-typings) or (b) install it by default for a while with ember-cli-typescript – just put it at <app>/typings/unsafe-ember and then… do a meaningless import somewhere with a comment explaining what it's for? Add it to application.ts or something?

In (a) we'd document how to opt into the unsafe typings; in (b) we'd document how to opt out. I prefer (b) between those two because it allows for the gradual typing approach, as we all noted in Slack.

[dwickern]

I wonder if DT would accept typings for a nonexistent module. Do we need to squat ember-unsafe-typings?

[dfreeman]

Does DT need to be involved at all? Could ember-unsafe-typings just be a published package with a types field in its package.json?

[dwickern]

True, we could publish a package with only typings, no code, and enable it with import 'ember-unsafe-typings'. I'd have to test if that can work

[dwickern]

I tested this out, it worked perfectly

[chriskrycho]

Let's do it.

[dwickern]

ember-unsafe-typings is mostly working. I copied over the tests from this PR. The "test suite" simply calls tsc.

You'll have a runtime error when you import the nonexistent module from an ember app. I need to set up a vendor shim or remove the import somehow at build time.

[chriskrycho]

@dwickern do we want to come back and pick this up and publish it? I think it's still valuable.