I've created a v8 branch that we can use for bugfixes against the current major if we need it.
The main / master branch will be used for implementing the modernizations
Some high-level things that need to happen
[ ] have a single migration path with backwards (or co-mingled) compatibility between old and new, as it'll take some time for a major release to propagate the ecosystem
[ ] this may require a monorepo setup so we can configure a app + addon combo that uses old ember-fetch with the new one (and test that they work without stomping on each other)
[ ] first, we'd want to convert to a single-package monorepo
[ ] probably switch to pnpm
[ ] we need to import from "ember-fetch", not "fetch"
[ ] we need to remove the build time code
[ ] update infra / ci / etc
[ ] probably switch to pnpm
[ ] convert to v2-addon (native package)
this would allow v2 addons to use ember-fetch
[ ] retain the test/waiter wrapping around fetch
[ ] we don't want to add this to @ember/test-waiters by default, because that would break folks' apps who aren't using ember-fetch but are using native fetch. The waiting-capabilities around ember-fetch that we have today should be opt in, as they are today
test-waiters could still provide the ultility to import to make fetch behave like the ember-fetch implementation does today -- and then ember-fetch can import that utility and wrap fetch with an export so that folks can import an instrumented fetch (behaving similar to what the existing import does)
[ ] drop support for node < 18 (so we can use native fetch)
[ ] drop support for IE11 (which doesn't inherently affect ember < 4, so 3.x can be supported with this one caveat)
I've created a
v8
branch that we can use for bugfixes against the current major if we need it.The
main
/master
branch will be used for implementing the modernizationsSome high-level things that need to happen
ember-fetch
with the new one (and test that they work without stomping on each other)"ember-fetch"
, not"fetch"
ember-fetch
@ember/test-waiters
by default, because that would break folks' apps who aren't using ember-fetch but are using native fetch. The waiting-capabilities around ember-fetch that we have today should be opt in, as they are today test-waiters could still provide the ultility to import to make fetch behave like the ember-fetch implementation does today -- and then ember-fetch can import that utility and wrapfetch
with an export so that folks can import an instrumented fetch (behaving similar to what the existing import does)Be sure to read through