search

fable-compiler / fable-compiler.github.io

Fable web site
https://fable.io
23 stars 64 forks source link

Add Fable.Packages link + documentation on how to setup a Fable package to make it compatible #142

Closed MangelMaxime closed 1 year ago

MangelMaxime commented 1 year ago

@alfonsogarciacaro @ncave @dbrattli @Zaid-Ajaj @alexswan10k

Can you please review the docs/docs/your-fable-project/author-a-fable-library.md update?

This document serves 2 purposes:

  1. It explain the implementation that has been choose for Fable.Packages
  2. Serve as documentation for library authors to setup their packages
gitpod-io[bot] commented 1 year ago

ncave commented 1 year ago

@MangelMaxime @alfonsogarciacaro Do we need a fable-typescript tag as well?

alfonsogarciacaro commented 1 year ago

@ncave That's a tricky one. Ideally all fable-javascript packages should be compatible with typescript (when it's on par with JS feature-wise), but it's true if the package emits JS code in some cases it may not be compatible with TypeScript 🤔

I would say that we don't need to make the distinction for now. Later if typescript becomes more general we may need to update the packages in a case-by-case basis.

MangelMaxime commented 1 year ago

I agree with @alfonsogarciacaro in that we don't need to make TypeScript a specific tag yet and see how it plays out. If needed, in the future we can begin supporting that tag.

Below are some discussion about JavaScript/TypeScript that happened in https://github.com/fable-compiler/packages/issues/1

@alexswan10k

Not really given this much thought, but Is it worth considering if there is overlap between typescript and javascript? They are technically separate targets but share the same library & one is a superset of the other etc.

@MangelMaxime

I know I was forgetting one language in my list but couldn't find which one ahah.

Hum, well in theory any package written fable:javascript is compatible with TypeScript target and vice versa.

I think it is would be easier to make only fable:javascript exist as this is the actual runtime. For JavaScript/TypeScript language distinction, I believe this more for the end user to decide which file he needs for his use case.

@alexswan10k

I think this makes sense. All packages are basically javascript with potential typescript type annotations, so I guess for a binding, it would always be js. With supported languages though, this is a little more vague since Emit can now export type information. Type information will obviously not compile if you are targeting javascript and webpack-ing .js files.

MangelMaxime commented 1 year ago

I would like to release Fable.Packages next week if possible.

The only blocking point I see is if we go with fable-library tag or not :)

alfonsogarciacaro commented 1 year ago

It's a bit complicated, in some cases the distinction between library and binding may be blurry. E.g., Fable.Promise is listed as an example of a library, but it's also a binding for JS Promise API 🤔 In any case, I'm not sure if this distinction will be useful for users/authors. Maybe we can omit the library/binding tag for now and add it later if needed?

Anyways, I agree with you @MangelMaxime that it'd be nice to push this soon so we can announce it alongside the release of Fable 4. I trust your criteria to decide about the tags, so can you please merge when everything's ready?

MangelMaxime commented 1 year ago

Maybe we can omit the library/binding tag for now and add it later if needed?

I do think being able to make distinction between a binding or library can help searching.

Yes, Fable.Promise is special and for some libraries the boundaries can be a bit blurry. Technically, nothing prevent us to add both tags fable-library and fable-binding for now I am asking the user to make a choice because I think this will cover most of the use cases and I think making the decision will be easier for them.