Make pretender a peer dependency

[jherdman]

Let's let the consumer of this addon decide which version of Pretender
is best for them.

Important Notes

• Assumes Update yarn.lock #1388 has been merged.

• I haven't gone to the lengths of supporting Pretender v2 yet. A preliminary spike suggests that's a bit more work than just bumping the version number. (Note: the problem seems to be that Pretender has a dependency on a few polyfill libs, and these either aren't being picked up or loaded correctly)

Questions

• Mirage provides a shim for ES6 Pretender imports. Should that still be the case? If not we'll have to bump to much more modern Pretender.

[jherdman]

After looking a little more into this I think the peerDependency should be on ecli-pretender. What's not clear to me is how to "hoist" its work up into Mirage. I would love to pair on this with someone more knowledgeable, it's definitely exposing a gap in my understanding of ecli.

[samselikoff]

Why ecli-pretender and not just pretender?

[samselikoff]

Would auto-import obviate the need for ecli-pretender?

[jherdman]

The gist is that using Pretender means that you need to install a bunch of ancillary packages (see pretenderjs/pretender#221). It seems kind of wacky to duplicate this effort when @rwjblue has gone to the effort of doing this work for us in ecli-pretender. The challenge seems to be that nested addons are bit of a gong show. The gist is that you sort of have to "hoist" up some dependencies. This is the part I could use some help on.

[samselikoff]

I see. Ya this stuff is tricky... I personally don't know the right answer here

[jherdman]

Well, the ultimate goal I had when I started this was to get Pretender 2 working. I’m going to double back on that. We can return to this specific idea later pending any insight from someone more experienced on this matter.

…

On Mon, Oct 1, 2018 at 21:52 Sam Selikoff ***@***.***> wrote: I see. Ya this stuff is tricky... I personally don't know the right answer here — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#1389 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAM5Hmr5B-J7W-WrmceFoAMJ3SPP9nFks5ugsbmgaJpZM4XBCtf> .

[xg-wang]

Hi @jherdman sorry I just noticed this from cross reference.
I'm not sure is it good to make it a peer-dep. Just want to point out ember-cli-mirage is loading assets here. To consume pretender v2, the only breaking change for mirage should be import whatwg-fetch (assume pretenderjs/pretender#235 merged).

[jherdman]

@xg-wang many thanks for the response! Out of curiosity, why not make pretender a peer dep? It'd certainly give users greater control over which version of Pretender they could use?

[xg-wang]

@jherdman IMO mirage is a higher level abstraction than pretender, it should hide its underlying impl and just provide its DSL for app. It should be mirage rather than consuming app's duty to take care of pretender.

[samselikoff]

@xg-wang In an ideal world I'd agree, however the reality is that I don't have the time or resources to make every Pretender API that Mirage users would find valuable available via a Mirage-specific API. I made the choice at the beginning to expose this.pretender for exactly this reason, and folks have used it for things like tracking requests when that feature landed in Pretender.

I think in OSS projects like this, this compromised middle road is the best path forward – exposing the underlying bits in a way that doesn't compromise the higher level APIs, so folks who get stuck behind a limitation of Mirage's APIs can dig down further if they need or want to.

Question: Is there a way to make Pretender a peerDependency of Mirage, but for Mirage to "supply" a version by default if the host app doesn't explicitly install it?

[happycollision]

Could you not do something like the following? (And not make it a peer dep).

"pretender": "^1.6.1 || >=2.0.0",

[jherdman]

@samselikoff I think a reasonable compromise in the mean time is to do the Pretender upgrade (see #1392), and continue to chip away at this problem in general. This would at least unlock fetch support in the interim.

[xg-wang]

Sorry for the breaking change, I pushed another change to the pending PR in pretender. Link tested it won't break ember-cli-mirage tests.

[samselikoff]

After lots of back and forth, I think the best path forward today to solve this problem is to point people towards yarn resolutions.

npm peer dependencies are good in theory, but do not have widespread support among tooling layers nor adoption in our community. For instance, every addon technically has a peer dependency on ember-source, though none of them specify it.

Given the current state of things, dependencies seems to be the best place to put things that are conceptually peer dependencies.

If users want to override the version of a dependency like Pretender (or any other transitive dependency of their project), they can do so with yarn resolutions.

For more info check out #1497.