@windyroad/[email protected]

Patch Changes

• 599b478: Our build was producing invalid JS, as relative imports were missing file extensions.
  See Compiled JavaScript import is missing file extension #40878
  and "module": "node16" should support extension rewriting #49083
  for details about this issue.

  The xo-config for the Windy Road code style has been updated to check for extensions. This
  will occasionally lead to false positives for imports like
  import {setupServer} from 'msw/node'. These false positives can be disabled with an inline
  eslint rule. e.g. // eslint-disable-next-line n/file-extension-in-import

@windyroad/[email protected]

Patch Changes

• 599b478: Our build was producing invalid JS, as relative imports were missing file extensions.
  See Compiled JavaScript import is missing file extension #40878
  and "module": "node16" should support extension rewriting #49083
  for details about this issue.

  The xo-config for the Windy Road code style has been updated to check for extensions. This
  will occasionally lead to false positives for imports like
  import {setupServer} from 'msw/node'. These false positives can be disabled with an inline
  eslint rule. e.g. // eslint-disable-next-line n/file-extension-in-import

• Updated dependencies [599b478]

  • @windyroad/[email protected]
  • @windyroad/[email protected]
  • @windyroad/[email protected]
  • @windyroad/[email protected]

@windyroad/[email protected]

Patch Changes

• 599b478: Our build was producing invalid JS, as relative imports were missing file extensions.
  See Compiled JavaScript import is missing file extension #40878
  and "module": "node16" should support extension rewriting #49083
  for details about this issue.

  The xo-config for the Windy Road code style has been updated to check for extensions. This
  will occasionally lead to false positives for imports like
  import {setupServer} from 'msw/node'. These false positives can be disabled with an inline
  eslint rule. e.g. // eslint-disable-next-line n/file-extension-in-import

• Updated dependencies [599b478]

  • @windyroad/[email protected]
  • @windyroad/[email protected]

@windyroad/[email protected]

Patch Changes

• 599b478: Our build was producing invalid JS, as relative imports were missing file extensions.
  See Compiled JavaScript import is missing file extension #40878
  and "module": "node16" should support extension rewriting #49083
  for details about this issue.

  The xo-config for the Windy Road code style has been updated to check for extensions. This
  will occasionally lead to false positives for imports like
  import {setupServer} from 'msw/node'. These false positives can be disabled with an inline
  eslint rule. e.g. // eslint-disable-next-line n/file-extension-in-import

• Updated dependencies [599b478]

  • @windyroad/[email protected]

@windyroad/[email protected]

Patch Changes

• 599b478: Our build was producing invalid JS, as relative imports were missing file extensions.
  See Compiled JavaScript import is missing file extension #40878
  and "module": "node16" should support extension rewriting #49083
  for details about this issue.

  The xo-config for the Windy Road code style has been updated to check for extensions. This
  will occasionally lead to false positives for imports like
  import {setupServer} from 'msw/node'. These false positives can be disabled with an inline
  eslint rule. e.g. // eslint-disable-next-line n/file-extension-in-import

• Updated dependencies [599b478]

  • @windyroad/[email protected]

@windyroad/[email protected]

Patch Changes

• 6b0973b: **/*.bench.ts files are now treated as development files

@windyroad/[email protected]

Major Changes

• d85098a: BREAKING CHANGE: We have had to modify the the template parameters for wrapFetch,
  decorateFetchResponse, adaptFetchInputs, addFragmentSupportToFetch, fetchFragment
  and fetchLink, replacing the FetchImpl parameter with and Arguments and ResponseType
  parameter. Originally the intention was to try and leverage Typescript's
  type inference and have it figure out the types based on the passed in fetch implementation,
  but we couldn't figure out how to make it work properly and we were getting lots of type
  errors. Replacing the FetchImpl parameter with the Arguments and ResponseType parameters solve those errors.

  fetchLink will now check if the link has a fragment and use that to return a fragment
  response instead of fetching the resource and getting the fragment from it. For iterating
  over items in a collection, this is orders of magnitude faster.

@windyroad/[email protected]

Major Changes

• d85098a: BREAKING CHANGE: We have had to modify the the template parameters for wrapFetch,
  decorateFetchResponse, adaptFetchInputs, addFragmentSupportToFetch, fetchFragment
  and fetchLink, replacing the FetchImpl parameter with and Arguments and ResponseType
  parameter. Originally the intention was to try and leverage Typescript's
  type inference and have it figure out the types based on the passed in fetch implementation,
  but we couldn't figure out how to make it work properly and we were getting lots of type
  errors. Replacing the FetchImpl parameter with the Arguments and ResponseType parameters solve those errors.

  fetchLink will now check if the link has a fragment and use that to return a fragment
  response instead of fetching the resource and getting the fragment from it. For iterating
  over items in a collection, this is orders of magnitude faster.

Minor Changes

• 3e3ea6c: Links for JSON responses that have a fragment identifier now include the matched fragment.
  For collections, this provides an easy and fast way to iterate over the items on the
  collection. While it is possible to call fetchLink for each fragment link, that is much
  slower due to network overheads and the serialisation of the json into a Response.
• 6169097: FragmentResponse now includes a reference to the related response, in an optional
  parent property, which can be used to access other fragments in the response

Patch Changes

• Updated dependencies [d85098a]
• Updated dependencies [6169097]
  • @windyroad/[email protected]
  • @windyroad/[email protected]
  • @windyroad/[email protected]
  • @windyroad/[email protected]

@windyroad/[email protected]

Major Changes

• d85098a: BREAKING CHANGE: We have had to modify the the template parameters for wrapFetch,
  decorateFetchResponse, adaptFetchInputs, addFragmentSupportToFetch, fetchFragment
  and fetchLink, replacing the FetchImpl parameter with and Arguments and ResponseType
  parameter. Originally the intention was to try and leverage Typescript's
  type inference and have it figure out the types based on the passed in fetch implementation,
  but we couldn't figure out how to make it work properly and we were getting lots of type
  errors. Replacing the FetchImpl parameter with the Arguments and ResponseType parameters solve those errors.

  fetchLink will now check if the link has a fragment and use that to return a fragment
  response instead of fetching the resource and getting the fragment from it. For iterating
  over items in a collection, this is orders of magnitude faster.

Minor Changes

• 6169097: FragmentResponse now includes a reference to the related response, in an optional
  parent property, which can be used to access other fragments in the response

Patch Changes

• Updated dependencies [d85098a]
  • @windyroad/[email protected]
  • @windyroad/[email protected]

@windyroad/[email protected]

Major Changes

• d85098a: BREAKING CHANGE: We have had to modify the the template parameters for wrapFetch,
  decorateFetchResponse, adaptFetchInputs, addFragmentSupportToFetch, fetchFragment
  and fetchLink, replacing the FetchImpl parameter with and Arguments and ResponseType
  parameter. Originally the intention was to try and leverage Typescript's
  type inference and have it figure out the types based on the passed in fetch implementation,
  but we couldn't figure out how to make it work properly and we were getting lots of type
  errors. Replacing the FetchImpl parameter with the Arguments and ResponseType parameters solve those errors.

  fetchLink will now check if the link has a fragment and use that to return a fragment
  response instead of fetching the resource and getting the fragment from it. For iterating
  over items in a collection, this is orders of magnitude faster.

Patch Changes

• Updated dependencies [d85098a]
  • @windyroad/[email protected]