Strawman proposal for providing Fantasyland Stream type in a separate package

[semmel]

This is a proposal how one can provide @most/core-fl by rebuilding @most/core and wrapping the Stream type with a FantasylandStream type.

• no import @most/core, so everything remains in TypeScript,
• @most/core-fl is 100% backwards compatible to @most/core

The implementation is simple, however the typings get quite laborious

See Fantasyland support issue

[briancavalier]

The overall approach here looks good, @semmel. Thanks!

My current thinking is that this could be a separate package in most-community. What do you think?

[briancavalier]

There's probably some discussion to be had on what a proper stream monoid should be. There might even be more than 1 valid monoid instance.

The way you've used continueWith here is nice. It's like a simple switch. I've come to believe that merge is also a pretty good semigroup.

Any thoughts or insights on which might be the better default semigroup instance? Are there others? See my other, related comment about zero as well.

[briancavalier]

The way I read the FL spec, @more/core-fl would also need to implement alt. Is that right?

It seems like you'll need to ensure that concat+empty are coherent, as are alt+zero. Have you thought about what makes sense for those in terms of coherence and their laws?

[semmel]

My current thinking is that this could be a separate package in most-community. What do you think?

Yes, of course.

But is it smart to use TypeScript for that community package then? (Could be just a matter of personal taste though). For example I could rather implement the FL wrapper in JS:

1. I'd import {ap, continueWith, …} from '@most/core' which is ES5 code generated from TypeScript.
2. in JS implement fantasyland(stream) returning a simple JS Object
3. author TS typings in index.d.ts using '@most/types' separate from the JS implementation
4. Then for my exports (nearly all of the @most/core API) I'd create a dist bundle which re-bundles to ES5?

I am not particular keen of working in TypeScript, but I value the type definitions.

Would it be better (e.g. aid debugging) if @most/core/dist/indes.es.js would be ES2020 and not ES5?
That would be a breaking change of course.

[briancavalier]

Yes, of course.

Great!

But is it smart to use TypeScript for that community package then? (Could be just a matter of personal taste though).

It's totally up to you. You'll own the repo and the package, so if you prefer to build in JS and include .d.ts files for types (or not), that's totally cool with us 😄 . When you're ready, you can open an issue here to request membership, and we'll add you as a collaborator.

For example I could rather implement the FL wrapper in JS:

1-3 all sound fine to me.

4. Then for my exports (nearly all of the @most/core API) I'd create a dist bundle which re-bundles to ES5?

There might be other options, but I can think of two you could consider:

1. Make @most/core a dependency and bundle it with your package.
2. Make @most/core a peerDependency, not bundled with your package, and devs install it into their project separately.

I think 2 could be a bit more helpful for existing projects that are already using @most/core and want to start using it via your new fantasy-land package.

Would it be better (e.g. aid debugging) if @most/core/dist/indes.es.js would be ES2020 and not ES5?

Yeah, you're right that targeting a new ES version is probably best. I'm not sure when we'll get to it, but I agree it's a good idea.