v3.0.0

What's Changed

This is the last release for the package domain-functions.

From v4 onwards the package is called composable-functions.

This version was published to facilitate the incremental migration from one lib to another.

It should be a smooth upgrade and with this version the composable-functions library is already available, you should be able to work with both libraries in the same codebase.

To read more about the migration, check out the docs.

New migration helpers:

• fromComposable: A function that turns a composable into a domain function at both type and runtime levels.

// In a module with a lot of domain functions
import { pipe, mdf, fromComposable } from 'domain-functions'
import { myFn } from './module-with-composables'

const fn = mdf()(() => "hello world")
const composition = pipe(fn, fromComposable(myFn))

• toComposable : A function to turn your domain functions into composables. It should work at both type and runtime levels.

// In a module with composables
import { pipe, composable } from 'composable-functions'
import { toComposable } from 'domain-functions'
import { myFn } from './module-with-dfs'

const fn = composable(() => "hello world")
const composition = pipe(fn, toComposable(myFn))

Breaking changes

• If you throw a string or any object that does not extend Error, the message in the Result type will be encoded as JSON.

const handler = mdf(z.object({ id: z.number() }))(() => {
  throw 'Error'
})

const result = await handler({ id: 1 })
/* result will contain: 
{    
  success: false,
  errors: [{ message: '"Error"' }], 
  inputErrors: [],
  environmentErrors: []
}
*/

When throwing something like {aCustomObject: 'my message'} this would also be encoded in the message field.

The recommended solution is to use instances of Error, however, you can use something like result.errors.map((e) => {...e, message: JSON.parse(e.message)}) if this pattern is common in your code for a smooth migration.