Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Confusion about the correct way to import from fp-ts #1606

Closed
CarstenLeue opened this issue Oct 22, 2021 · 9 comments
Closed

Confusion about the correct way to import from fp-ts #1606

CarstenLeue opened this issue Oct 22, 2021 · 9 comments

Comments

@CarstenLeue
Copy link

CarstenLeue commented Oct 22, 2021

📖 Documentation

I love fp-ts and I appreciate the good documentation. However I think that in most documentation the examples do not illustrate the "correct" way to import from fp-ts.

Example: https://dev.to/gcanti/getting-started-with-fp-ts-monad-6k

The examples show e.g:

import { Option, some, none, option } from 'fp-ts/lib/Option'

On the other hand #1241 has added support for es6 imports that work well with tree shaking. This way of importing leaves the choice to the importing tool what version to consume, the commonjs or the es6 version (which is the recommended way to import). An example is:

import { Option, some, none, option } from 'fp-ts/Option'

When mixing imports however we end up with multiple copies of fp-ts being used. This not only increases the size of the final bundle (if packed), it also breaks the concept of singletons. The constant Option.none e.g. is probably supposed to be a singleton, but we end up with different instances depending on how fp-ts gets imported.
Libraries from the ecosystem address this via a post-processing step using import-path-rewrite which results in a correct result, by explicitly importing from fp-ts/es6 for the es6 case. But this is basically unnecessarily complex, an import directly from fp-ts would work fine both for the es6 and the commonjs case, because of the entries main and modules in the package.json files. For exploiters of fp-ts it is also very easy to get this wrong, since the examples point to the commonjs import style, only.

I suggest to clarify the intended import style in the fp-ts documentation and - if possible - rework the documentation to use the import directly from fp-ts instead of from fp-ts/lib.

@CarstenLeue
Copy link
Author

CarstenLeue commented Oct 22, 2021

Related: #1003, #1044

@gcanti
Copy link
Owner

gcanti commented Oct 27, 2021

blog posts amended

@luisincrespo
Copy link

blog posts amended

@gcanti which blog posts are you referring to? Thanks!

@gcanti
Copy link
Owner

gcanti commented Apr 5, 2023

@danielo515
Copy link

@luisincrespo https://dev.to/gcanti/series/680

That seems to be only a list of blog posts, and I don't see anything specific to this question. Do you mind a direct link?

@gcanti
Copy link
Owner

gcanti commented Oct 24, 2023

@danielo515 the correct way to import from fp-ts is

import ... from 'fp-ts/<module>'

example with Option:

import * as Option from 'fp-ts/Option'

@danielo515
Copy link

danielo515 commented Oct 24, 2023 via email

@gcanti
Copy link
Owner

gcanti commented Oct 24, 2023

@danielo515 in the src folder I found these #1913, are there others?

@danielo515
Copy link

danielo515 commented Oct 24, 2023 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants