Open SRachamim opened 4 years ago
It's already solved. Search in issues. Webpack 5 will tree-shake it properly.
What already solved? Tree-shaking is not the issue here.
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
andes6
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'
butimport { 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.
🚀 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:
Desired Behavior
I'de like to find everything on the index:
Suggested Solution
It could be better to pascal-case all modules on
index.ts
, and to export all types, allfunction
utilities andpipe
.Consider also to export very handy utilities like
sequence
andtraverse
.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.