Base dependencies to be used in the playground

[GiregL]

Hi

Since some of the stdlib is moved into separate packages, I thought it could be useful to add those dependencies in the playground, so that we can still use them.
i.e. adding gleam_yielder, gleam_deque and so on.

[lpil]

How would we decide what packages are included? Download counts?

gleam_yielder, and gleam_deque don't seem like very good candidates to me, they are uncommon packages to use.

[GiregL]

Download count could be an indication but with time, big libraries will end up in the playground.

And even if yielder or deque are uncommon, it can be useful to try them before considering using them in projects, or even just to understand how they work

[lpil]

We definitely do not want to direct people towards those packages by default.

[Beanow]

Aside from the dilemma of choosing the packages, I tinkered with this idea for a while and made some progress.
Here's the globlin code example.

It involves changes across the stack though (including gleam-wasm).
But in short:

• Add more files to the precompiled directory (basically a subset of build/dev/javascript, including _gleam_artefacts).
• Generate a different file manifest js file for this.
• Load them as binary into /lib instead of /src in the wasm compiler.
• Added support to the wasm compiler to load these as precompiled packages.
• Update some of the from "..." imports accordingly.

[Beanow]

How would we decide what packages are included? Download counts?

When it comes to choosing packages, how about one of these three:

1. Only gleam_stdlib like we do currently.
2. All gleam_* packages because they are explicitly marked as "official Gleam packages".
3. All packages that are allowed to be on https://packages.gleam.run/

Because I think that Playground is an official resource, it should probably care more about what's right for the overall community, rather than convenience. We can debate what "right for the community" means, but remaining neutral on what packages you should use (whether endorsing or discouraging) seems like one position you could take on that.

However by that logic gleam_yielder and gleam_deque make sense to me to include.
If it was chosen to be an "official package", that choice already gives it preferential featuring.
Regardless of whether they're popularly used, it's consistent with the "official" label.

Finally 3. would be a bit more challenging to implement, but would be a sensible official selection of packages.

At this scale we'd probably need to switch from precompiling to downloading and compiling as-needed.
Note that this option does not mean you can run whatever you want. It excludes path or git dependencies or alternative repositories. And it means it needs to work with gleam, and be acceptable for publishing on hex.

[Beanow]

Some prior art the Go playground lets you run imports (not sure if it's a subset).
https://play.golang.com/p/IReRqgHqt5m

Rust playground picks the top 100 by downloads.
https://github.com/rust-lang/rust-playground/blob/75cdc9a24b3e4d5e6ce990e300cc1eaf898a5b70/top-crates/src/lib.rs#L126
(Running the compiler on a server without network connection)

Compiler Explorer does have a limited selection of Rust crates, not sure based on what.