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

[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.