NPM @fp-ts/*

[waynevanson]

Is it worth having the NPM scope @fp-ts? It seems to be available. https://www.npmjs.com/search?q=%40fp-ts

If so, I wonder how it could be structured.

How to:

• Distinguish core from non-core files?
• Distinguish what is and is not officially supported?
• Different environments

List of possibilities, without too much thought.

@fp-ts

• /core
• /std
• /node
• /dom-browser
• /HKT
• /testing
• /dom-mobile (eg. Touch API's)
• /core
• /derive
• /<every-package-under-the-sun>

Pros:

• Standardized infrastructure and build systems.
• Interlace GitHub actions to test changes from one repos across all.
• Some modules can reexport namespaces based on environment (/dom-mobile, dom-browser).
• Start to figure out what's missing in the space to make fp-ts a standard within an enterprise setting.
• Standard naming convention: @fp-ts/<name> instead of <name>-ts, fp-ts-<name> and fp-<name>.
• Quality control for officially supported packages.

Cons:

• If we start with a real messed up structure, it'll be a pain to fix.
• Decide what tools are the best tools to use (ie. yarn or npm for package management?)
• Typescript versioning. They don't follow semantic versioning, so future versions within "compatible" versions are breaking.
• Timing. Waiting for typescript features like parametric types to be added, as this is a game changer.
• Time. Surely something like this takes a lot of time.

[derrickbeining]

FYI, I nabbed the fp-ts org name on npmjs.org a while back in order to reserve it for the fp-ts ecosystem should gcanti ever want to go that direction. Happy to give gcanti ownership whenever he wants it.

[gcanti]

Hi @derrickbeining, I'm working on fp-ts@v3 and it would be nice to release the next version under the fp-ts org name, let me know if it's ok for you, thanks!

[samhh]

Would there be any interest in adopting/integrating community packages? I think fp-ts-std may make a good foundation for something like an @fp-ts/extra.

[adrian-gierakowski]

@samhh there is https://github.com/gcanti/fp-ts-contrib

[samhh]

That can form the foundation, but it's a bit disorganised at the moment - I'd anticipate an extra/contrib library sharing the same structure as core. Equally a lot of the stuff that's moved into fp-ts proper isn't really fundamental and perhaps better belongs in contrib than core.