The meta from gleam-community

meta's Introduction

Who is gleam-community?

While we may have different maintainers for each project, you can always reach out to the organisation's admins.

What kind of packages are maintained by gleam-community?

As we are not affiliated with the core Gleam organisation, we are free to maintain whatever packages we think might be useful. With that in mind, we have a few guidelines for what constitutes a good fit for the organisation:

Does the package have broad appeal to the Gleam community? Is it useful in most, if not all, Gleam targets: BEAM, Node.js, Deno, browsers, etc.
Is there only one or a handful of possible implementations, and does the community benefit from having a single, high-quality implementation vs. a choice of multiple individually-maintained implementations?
Are there critical performance requirements or expectations, and can the organisation meet them?
Is it possible the package could be maintained by the core Gleam organisation in the future? If so, would they benefit from

From time to time we may choose to maintain packages that don't fit these guidelines. For example, we may choose to maintain a package that is only useful for a single target if the value it provides is significant enough. For the most part, however, the above guidelines will give you a good idea of what we're doing here.

Can I contribute to a gleam-community package?

Yes, it's in our name! Our aim isn't to be a handful of "blessed" contributors: we welcome contributions from anyone who wants to help. Opening issues, expanding tests, or improving documentation are all great ways to contribute.

PRs are also welcome, but we ask that you open an issue first to discuss the change you'd like to make.

I have an idea for a package, what can I do?

We don't have a formal process for this yet, so the best way would be to ping one of us on the Gleam Discord server and we can discuss it from there. Be mindful that we ask folks pitching ideas to make sure it roughly fits the guidelines above and that they are willing to maintain the package over the long-term.

meta's People

Contributors

Stargazers

Watchers

meta's Issues

potential package: uuid

probably only v4, maybe v5 and v8 too if we're feeling spicy

potential package: assert

Implementation would probably be mostly two functions

`assert_or_die`

pub fn assert_or_die(val: Bool) {
  case val {
    True -> val
    False -> panic
  }
}

Use case

pub fn process_data(important_data: Data) {
  assert_or_die(isValidSignature(important_data.signature))
  // do things with data
}

This is useful, especially for hacking things out quickly, but isn't very idiomatic, hence the need for our second implementation.

`assert_or_error`

pub fn assert_or_error(val: Bool, error: e, func: fn() -> a) -> Result(a, e) {
  case val {
    True -> Ok(func())
    False -> Error(error)
  }
}

Use case

pub type DataProcessingError {
  InvalidSignature
}

pub fn process_data(important_data: Data) -> Result(a, DataProcessingError) {
  use <- assert_or_error(isValidSignature(important_data.signature), InvalidSignature)
  // do things with data
}

This still allows us to make assumptions in our code, but allows us to propagate errors instead of killing the program outright.

gleam-community / meta Goto Github PK

meta's Introduction

Who is gleam-community?

What kind of packages are maintained by gleam-community?

Can I contribute to a gleam-community package?

I have an idea for a package, what can I do?

meta's People

Contributors

Stargazers

Watchers

meta's Issues

potential package: uuid

potential package: assert

`assert_or_die`

Use case

`assert_or_error`

Use case

potential package: maths

Recommend Projects

React

Vue.js

Typescript

TensorFlow

Django

Laravel

D3

Recommend Topics

javascript

web

server

Machine learning

Visualization

Game

Recommend Org

Facebook

Microsoft

Google

Alibaba

D3

Tencent