Effect-TS / effect

What is the type of issue?

Documentation is confusing

What is the issue?

Description:

There is a discrepancy between the documentation for the pipe function on the Effects website and the actual import behavior observed in the code.

Issue:

The Effects documentation website suggests importing the pipe function using the following syntax:

import { pipe } from "effect";

However, upon importing and hovering over the code, the example section suggests a different import path:

@example

import { pipe } from "effect/Function"

Expected Behavior:

The documentation and the actual import behavior should align to provide consistent and accurate guidance to users.

Where did you find it?

Effect Docs - Building Pipelines

Both are valid, but yes, the effect import is probably the more idiomatic one for application code (the effect entrypoint re-exports it from effect/Function). You will find the same in a lot of examples around the codebase.

@gcanti Should we change all these imports across our @examples to effect instead? I can see how this might be confusing.

changing all the imports would just cause the opposite confusion. We just need to patch up the Importing Effect section of the site. This is the first page before even the effect type itself, it makes sense for it to be read

changing all the imports would just cause the opposite confusion. We just need to patch up the Importing Effect section of the site. This is the first page before even the effect type itself, it makes sense for it to be read

We will have more ppl writing app code than lib code. So imho we should optimize for that.

@fubhy I think we need to standardize the imports, for example:

from

effect/packages/effect/src/Option.ts

Lines 179 to 180 in 2e1cdf6

    
            * import { some, none, match } from 'effect/Option' 
        
            * import { pipe } from "effect/Function"

to

import { pipe, Option } from "effect"

As for the pipe example, I would show both imports with a comment:

import { pipe } from "effect/Function"
// Alternatively, you can use the following import syntax, as `pipe` is also conveniently exported from the `effect` entry point:
// import { pipe } from "effect"

const length = (s: string): number => s.length
const double = (n: number): number => n * 2
const decrement = (n: number): number => n - 1

assert.deepStrictEqual(pipe(length("hello"), double, decrement), 9)

we can err on the side of ergonomics and dx or err on the side of making the bundler happy, but not both it seems..
Also we need to take into account that even in app-code people have plenty of internal libs which should optimally use lib-appropriate practices. I think defaulting to everything from "effect" with a more robust explanation in the Importing Effect section about how to optimize for bundlers would be the best.

That said, learning from others, they tend to default the other way around. For example MUI always write their imports

import Button from "@mui/core/Button"

despite auto-import finding the named export in the root

import { Button } from "@mui/core"

	* import { some, none, match } from 'effect/Option'
	* import { pipe } from "effect/Function"