You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 todaytest-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)Be sure to read through
The text was updated successfully, but these errors were encountered: