Publish packages 🚀

[lemonmade]

This PR was opened by the Changesets release GitHub action. When you're ready to do a release, you can merge this and the packages will be published to npm automatically. If you're not ready to do a release yet, that's fine, whenever you add more changesets to main, this PR will be updated.

Releases

@quilted/threads@3.0.0

Major Changes

• #816 ecd7322 Thanks @lemonmade! - Changed ThreadAbortSignal utilities to be class-based instead of being a collection of utility functions. This change aligns the API more closely with AbortController in the browser, which is created with new AbortController().

  Previously, you used createThreadAbortSignal() to serialize an AbortSignal to pass over a thread, and acceptThreadAbortSignal() to turn it into a “live” AbortSignal. With the new API, you will do the same steps, but with ThreadAbortSignal.serialize() and new ThreadAbortSignal:

  import {
    createThreadAbortSignal,
    acceptThreadAbortSignal,
  } from '@quilted/threads';
  
  const abortController = new AbortController();
  const serializedAbortSignal = createThreadAbortSignal(abortController.signal);
  const liveAbortSignal = acceptThreadAbortSignal(serializedAbortSignal);
  
  await fetch('/', {signal: liveAbortSignal});
  
  // Becomes:
  
  import { ThreadAbortSignal } from '@quilted/threads';\
  
  const abortController = new AbortController();
  const serializedAbortSignal = ThreadAbortSignal.serialize(abortController.signal);
  const liveAbortSignal = new ThreadAbortSignal(serializedAbortSignal);
  
  await fetch('/', {signal: liveAbortSignal});

  Additionally, the new ThreadAbortSignal class assumes you are not doing manual memory management by default. If your target environment does not support automatic memory management of transferred functions, you will need to manually pass the retain and release functions to the new APIs:

  import {retain, release, ThreadAbortSignal} from '@quilted/threads';
  
  const abortController = new AbortController();
  const serializedAbortSignal = ThreadAbortSignal.serialize(
    abortController.signal,
    {retain, release},
  );
  const liveAbortSignal = new ThreadAbortSignal(serializedAbortSignal, {
    retain,
    release,
  });
  
  await fetch('/', {signal: liveAbortSignal});

• #813 40c2d71 Thanks @lemonmade! - Refactored the API for creating threads. The new APIs are class based, and now use module-style language to define the functions shared between threads: exports when creating a thread indicates the methods that can be called, and imports allows you to call those methods in the paired thread.

  For example, you previously used createThreadFromWebWorker() to create a thread from a web worker. Now, you use the ThreadWebWorker class:

  // Old API:
  import {createThreadFromWebWorker} from '@quilted/threads';
  
  // Parent page
  const worker = new Worker('worker.js');
  const thread = createThreadFromWebWorker(worker);
  const result = await thread.doWork();
  
  // Worker
  createThreadFromWebWorker(self, {
    expose: {
      async doWork() {
        /* ... */
      },
    },
  });
  
  // ---
  // New API:
  import {ThreadWebWorker} from '@quilted/threads';
  
  // Parent
  const worker = new Worker('worker.js');
  const thread = new ThreadWebWorker(worker);
  const result = await thread.imports.doWork();
  
  // Worker
  new ThreadWebWorker(worker, {
    exports: {
      async doWork() {
        /* ... */
      },
    },
  });

  Additionally, the threads library now exports two additional helpers for turning web objects into threads: ThreadWindow and ThreadNestedWindow, which can be used to create a communication channel between a parent page and popup windows or tabs.

• #818 8669216 Thanks @lemonmade! - Changed Preact thread utilities to be class-based instead of being a collection of utility functions.

  Previously, you used createThreadSignal() to serialize a Preact signal to pass over a thread, and acceptThreadSignal() to turn it into a "live" signal. With the new API, you will do the same steps, but with ThreadSignal.serialize() and new ThreadSignal():

  import {signal, computed} from '@preact/signals-core';
  import {ThreadWebWorker, ThreadSignal} from '@quilted/threads';
  
  // Old API:
  const result = signal(32);
  const serializedSignal = createThreadSignal(result);
  await thread.imports.calculateResult(serializedSignal);
  
  // New API:
  const result = signal(32);
  const serializedSignal = ThreadSignal.serialize(result);
  await thread.imports.calculateResult(serializedSignal);
  
  // In the target thread:
  
  // Old API:
  function calculateResult(resultThreadSignal) {
    const result = acceptThreadSignal(resultThreadSignal);
    const computedSignal = computed(
      () => `Result from thread: ${result.value}`,
    );
    // ...
  }
  
  // New API:
  function calculateResult(resultThreadSignal) {
    const result = new ThreadSignal(resultThreadSignal);
    const computedSignal = computed(
      () => `Result from thread: ${result.value}`,
    );
    // ...
  }

Patch Changes

• Updated dependencies [8669216]:
  • @quilted/events@2.1.1

@quilted/preact-workers@0.2.0

Minor Changes

• #813 40c2d71 Thanks @lemonmade! - Refactored the API for creating threads. The new APIs are class based, and now use module-style language to define the functions shared between threads: exports when creating a thread indicates the methods that can be called, and imports allows you to call those methods in the paired thread.

  For example, you previously used createThreadFromWebWorker() to create a thread from a web worker. Now, you use the ThreadWebWorker class:

  // Old API:
  import {createThreadFromWebWorker} from '@quilted/threads';
  
  // Parent page
  const worker = new Worker('worker.js');
  const thread = createThreadFromWebWorker(worker);
  const result = await thread.doWork();
  
  // Worker
  createThreadFromWebWorker(self, {
    expose: {
      async doWork() {
        /* ... */
      },
    },
  });
  
  // ---
  // New API:
  import {ThreadWebWorker} from '@quilted/threads';
  
  // Parent
  const worker = new Worker('worker.js');
  const thread = new ThreadWebWorker(worker);
  const result = await thread.imports.doWork();
  
  // Worker
  new ThreadWebWorker(worker, {
    exports: {
      async doWork() {
        /* ... */
      },
    },
  });

  Additionally, the threads library now exports two additional helpers for turning web objects into threads: ThreadWindow and ThreadNestedWindow, which can be used to create a communication channel between a parent page and popup windows or tabs.

Patch Changes

• Updated dependencies [40c2d71]:
  • @quilted/workers@0.5.0

@quilted/quilt@0.8.0

Minor Changes

• #813 40c2d71 Thanks @lemonmade! - Refactored the API for creating threads. The new APIs are class based, and now use module-style language to define the functions shared between threads: exports when creating a thread indicates the methods that can be called, and imports allows you to call those methods in the paired thread.

  For example, you previously used createThreadFromWebWorker() to create a thread from a web worker. Now, you use the ThreadWebWorker class:

  // Old API:
  import {createThreadFromWebWorker} from '@quilted/threads';
  
  // Parent page
  const worker = new Worker('worker.js');
  const thread = createThreadFromWebWorker(worker);
  const result = await thread.doWork();
  
  // Worker
  createThreadFromWebWorker(self, {
    expose: {
      async doWork() {
        /* ... */
      },
    },
  });
  
  // ---
  // New API:
  import {ThreadWebWorker} from '@quilted/threads';
  
  // Parent
  const worker = new Worker('worker.js');
  const thread = new ThreadWebWorker(worker);
  const result = await thread.imports.doWork();
  
  // Worker
  new ThreadWebWorker(worker, {
    exports: {
      async doWork() {
        /* ... */
      },
    },
  });

  Additionally, the threads library now exports two additional helpers for turning web objects into threads: ThreadWindow and ThreadNestedWindow, which can be used to create a communication channel between a parent page and popup windows or tabs.

Patch Changes

• #816 ecd7322 Thanks @lemonmade! - Changed ThreadAbortSignal utilities to be class-based instead of being a collection of utility functions. This change aligns the API more closely with AbortController in the browser, which is created with new AbortController().

  Previously, you used createThreadAbortSignal() to serialize an AbortSignal to pass over a thread, and acceptThreadAbortSignal() to turn it into a “live” AbortSignal. With the new API, you will do the same steps, but with ThreadAbortSignal.serialize() and new ThreadAbortSignal:

  import {
    createThreadAbortSignal,
    acceptThreadAbortSignal,
  } from '@quilted/threads';
  
  const abortController = new AbortController();
  const serializedAbortSignal = createThreadAbortSignal(abortController.signal);
  const liveAbortSignal = acceptThreadAbortSignal(serializedAbortSignal);
  
  await fetch('/', {signal: liveAbortSignal});
  
  // Becomes:
  
  import { ThreadAbortSignal } from '@quilted/threads';\
  
  const abortController = new AbortController();
  const serializedAbortSignal = ThreadAbortSignal.serialize(abortController.signal);
  const liveAbortSignal = new ThreadAbortSignal(serializedAbortSignal);
  
  await fetch('/', {signal: liveAbortSignal});

  Additionally, the new ThreadAbortSignal class assumes you are not doing manual memory management by default. If your target environment does not support automatic memory management of transferred functions, you will need to manually pass the retain and release functions to the new APIs:

  import {retain, release, ThreadAbortSignal} from '@quilted/threads';
  
  const abortController = new AbortController();
  const serializedAbortSignal = ThreadAbortSignal.serialize(
    abortController.signal,
    {retain, release},
  );
  const liveAbortSignal = new ThreadAbortSignal(serializedAbortSignal, {
    retain,
    release,
  });
  
  await fetch('/', {signal: liveAbortSignal});

• #818 8669216 Thanks @lemonmade! - Changed Preact thread utilities to be class-based instead of being a collection of utility functions.

  Previously, you used createThreadSignal() to serialize a Preact signal to pass over a thread, and acceptThreadSignal() to turn it into a "live" signal. With the new API, you will do the same steps, but with ThreadSignal.serialize() and new ThreadSignal():

  import {signal, computed} from '@preact/signals-core';
  import {ThreadWebWorker, ThreadSignal} from '@quilted/threads';
  
  // Old API:
  const result = signal(32);
  const serializedSignal = createThreadSignal(result);
  await thread.imports.calculateResult(serializedSignal);
  
  // New API:
  const result = signal(32);
  const serializedSignal = ThreadSignal.serialize(result);
  await thread.imports.calculateResult(serializedSignal);
  
  // In the target thread:
  
  // Old API:
  function calculateResult(resultThreadSignal) {
    const result = acceptThreadSignal(resultThreadSignal);
    const computedSignal = computed(
      () => `Result from thread: ${result.value}`,
    );
    // ...
  }
  
  // New API:
  function calculateResult(resultThreadSignal) {
    const result = new ThreadSignal(resultThreadSignal);
    const computedSignal = computed(
      () => `Result from thread: ${result.value}`,
    );
    // ...
  }

• Updated dependencies [ecd7322, 40c2d71, 8669216]:

  • @quilted/threads@3.0.0
  • @quilted/preact-workers@0.2.0
  • @quilted/events@2.1.1

@quilted/workers@0.5.0

Minor Changes

• #813 40c2d71 Thanks @lemonmade! - Refactored the API for creating threads. The new APIs are class based, and now use module-style language to define the functions shared between threads: exports when creating a thread indicates the methods that can be called, and imports allows you to call those methods in the paired thread.

  For example, you previously used createThreadFromWebWorker() to create a thread from a web worker. Now, you use the ThreadWebWorker class:

  // Old API:
  import {createThreadFromWebWorker} from '@quilted/threads';
  
  // Parent page
  const worker = new Worker('worker.js');
  const thread = createThreadFromWebWorker(worker);
  const result = await thread.doWork();
  
  // Worker
  createThreadFromWebWorker(self, {
    expose: {
      async doWork() {
        /* ... */
      },
    },
  });
  
  // ---
  // New API:
  import {ThreadWebWorker} from '@quilted/threads';
  
  // Parent
  const worker = new Worker('worker.js');
  const thread = new ThreadWebWorker(worker);
  const result = await thread.imports.doWork();
  
  // Worker
  new ThreadWebWorker(worker, {
    exports: {
      async doWork() {
        /* ... */
      },
    },
  });

  Additionally, the threads library now exports two additional helpers for turning web objects into threads: ThreadWindow and ThreadNestedWindow, which can be used to create a communication channel between a parent page and popup windows or tabs.

Patch Changes

• Updated dependencies [ecd7322, 40c2d71, 8669216]:
  • @quilted/threads@3.0.0

@quilted/cloudflare@1.0.0

Patch Changes

• Updated dependencies [ecd7322, 40c2d71, 8669216]:
  • @quilted/quilt@0.8.0

@quilted/deno@1.0.0

Patch Changes

• Updated dependencies [ecd7322, 40c2d71, 8669216]:
  • @quilted/quilt@0.8.0

@quilted/react-query@1.0.0

Patch Changes

• Updated dependencies [ecd7322, 40c2d71, 8669216]:
  • @quilted/quilt@0.8.0

@quilted/events@2.1.1

Patch Changes

• #818 8669216 Thanks @lemonmade! - Changed Preact thread utilities to be class-based instead of being a collection of utility functions.

  Previously, you used createThreadSignal() to serialize a Preact signal to pass over a thread, and acceptThreadSignal() to turn it into a "live" signal. With the new API, you will do the same steps, but with ThreadSignal.serialize() and new ThreadSignal():

  import {signal, computed} from '@preact/signals-core';
  import {ThreadWebWorker, ThreadSignal} from '@quilted/threads';
  
  // Old API:
  const result = signal(32);
  const serializedSignal = createThreadSignal(result);
  await thread.imports.calculateResult(serializedSignal);
  
  // New API:
  const result = signal(32);
  const serializedSignal = ThreadSignal.serialize(result);
  await thread.imports.calculateResult(serializedSignal);
  
  // In the target thread:
  
  // Old API:
  function calculateResult(resultThreadSignal) {
    const result = acceptThreadSignal(resultThreadSignal);
    const computedSignal = computed(
      () => `Result from thread: ${result.value}`,
    );
    // ...
  }
  
  // New API:
  function calculateResult(resultThreadSignal) {
    const result = new ThreadSignal(resultThreadSignal);
    const computedSignal = computed(
      () => `Result from thread: ${result.value}`,
    );
    // ...
  }