fp-ts

fp-ts copied to clipboard

🚀 Feature request

I find it hard to manually and automatically import functions, types and utilities.

Current Behavior

This is how a typical file of mine looks:

import { pipe } from 'fp-ts/lib/pipeable';
import { flow } from 'fp-ts/lib/function';
import { either } from 'fp-ts';
import { Either } from `fp-ts/lib/Either';

// weird use of proofs
either.either

const anEither: Either = either.right(5);

Desired Behavior

I'de like to find everything on the index:

import { pipe, flow, Either } from 'fp-ts';

// general name for proofs (I'm an fp-noob, so maybe there's a better name)
Either.proof

// Either is both the module and the type
const either: Either = Either.right(5);

Suggested Solution

It could be better to pascal-case all modules on index.ts, and to export all types, all function utilities and pipe.

Consider also to export very handy utilities like sequence and traverse.

Who does this impact? Who is this for?

Tree shaking is not always relevant. In those cases I prefer ergonomics: auto-import should work like a charm and import should be grouped so it would be easy to manually import additional utilities.

It's already solved. Search in issues. Webpack 5 will tree-shake it properly.

What already solved? Tree-shaking is not the issue here.

Hidden as the comments this was about are now deleted

Hey, let's keep the conversation civil and on track, because it becomes kinda heated.

@gcanti what do you think about adopting a Code of Conduct, such as https://www.contributor-covenant.org?

@steida: what @SRachamim proposes is indeed a little bit more ergonomic than the current status quo outlined in the comment that you linked too, IMO. Consider that you won't need to choose between lib and es6 when confirming automatic imports, and won't have to import types and functions that operate on those types from different modules separately (import { either } from 'fp-ts' but import { Either } from 'fp-ts/lib/Either').

@steida It's not hard to do what you recommend to me, it's just that I felt that my proposal wasn't clear enough.

The issue you linked to just talks about updating the documentation, while the current issue is a proposal to an entire shift in the import philosophy in the next major release.

@steida: what @SRachamim proposes is indeed a little bit more ergonomic than the current status quo outlined in the comment that you linked too, IMO. Consider that you won't need to choose between lib and es6 when confirming automatic imports, and won't have to import types and functions that operate on those types from different modules separately (import { either } from 'fp-ts' but import { Either } from 'fp-ts/lib/Either').

The problem with this is tree shakability, yes you wouldn't have to choose between es6 & lib but the advantage of using es6 is rendered useless by the missing deep scope analysis on the webpack < 5 & rollup shakers.

The best solution would be to expose modules like: import * as E from "fp-ts/Either"

This is possible by exposing each sub-package with it's own package.json referencing the esm module in "modules" like many other libraries do (e.g. @material-ui/core, @matechs/core)

I think this should be evaluated for v3 given it is really a pain point having to choose manually (or perform import-path-rewrite like the ecosystem libraries are forced to do)

I think typeclass is the correct keyword here and the most suitable candidate I can conjure up.