Fp-ts: import best practices

[steida]

📖 Documentation

When you are using both Option and IO, what is your best practice? * or aliasing?

import * as o from 'fp-ts/lib/Option';
import * as i from 'fp-ts/lib/IO';
import * as te from 'fp-ts/lib/TaskEither';

[DenisFrezzato]

I found myself (and I guess this is the more common approach among other fp-ts users) to import the whole module using the first letters of the module itself, for example:

import * as O from 'fp-ts/lib/Option'
import * as IO from 'fp-ts/lib/IO'
import * as TE from 'fp-ts/lib/TaskEither'

[raveclassic]

I find writing imports by hand tedious and always rely on autocomplete/autoimport. Firstly I tried aliasing (fixing clashes by hand) but finally came to named imports from fp-ts index:

import { option, either } from 'fp-ts';

[steida]

@raveclassic Interesting. Isn't either.Either verbose? Also, does it tree-shake?

[raveclassic]

@steida except types :) only either.map, either.chain etc.

Downside - the whole either.ts module is always added to the bundle but it's worth the DX. Actually you also get the whole module bundled when importing under *

[steida]

@raveclassic I like it. It's verbose but explicit and with autocomplete. As for tree shaking, it does not work reliably anyway when some other lib like monocle-ts is imported, because it will use /lib.

So, import { option, either } from 'fp-ts'; is ok and for tree shaking, we need imports rewriting anyway.

[steida]

@raveclassic Still, I would love to solve tree shaking across fp-ts ecosystem anyway. It seems it's almost ready.

[steida]

As a result, in the app, I would use import { option, either }.
In a lib, which is going to be tree shaked, it seems we have no other option than aliases. I doubt any tree shaking engine can optimize option.chain. It would have to solve clashes.