Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reorganize before an official release #25

Closed
ObsidianMinor opened this issue Sep 2, 2021 · 6 comments
Closed

Reorganize before an official release #25

ObsidianMinor opened this issue Sep 2, 2021 · 6 comments

Comments

@ObsidianMinor
Copy link

ObsidianMinor commented Sep 2, 2021

The naming of the crates in this project are a bit everywhere. It'd be nice to consolidate the names of everything and reorganize before committing to any crates.io releases.

As it stands there are currently five crates each with wildly different names:

  • edgeworker-sys
  • worker-rs-macros
  • libworker
  • worker
  • rust-worker-build

libworker could be dropped in favor of just defining everything in worker instead of using worker to re-export everything. Currently libworker is separate so it can be imported by worker-rs-macros however the macros crate never uses it so it's an unnecessary dependency. With the base name "worker", we can easily turn this into four separate easily identifiable crates.

  • worker-sys - For low-level FFI bindings
  • worker-macros - For macros
  • worker - For bringing everything together with convenience types
  • worker-build - As a build command

On top of this, it may be favorable to drop the rust-sandbox crate. Instead of testing or experimenting in a sandbox, things normally written in the sandbox would be better if written as an example in the worker crate. Then things written as examples for testing during development can be referenced later by users.

@nilslice
Copy link
Contributor

nilslice commented Sep 2, 2021

This is a good call, and thanks for suggesting names that are available on crates.io. Definitely needs some cleanup here now that the dust has settled a bit. I'll try to fit it in today and re-publish the crates under their new names.

On top of this, it may be favorable to drop the rust-sandbox crate. Instead of testing or experimenting in a sandbox, things normally written in the sandbox would be better if written as an example in the worker crate. Then things written as examples for testing during development can be referenced later by users.

This is all true, except I plan to add automated integration tests that will publish rust-sandbox and run curl commands against it. I don't blame you for suggesting we axe the crate though.. it looks like a bunch of nonsense :) I plan on cleaning it up to be more useful against integration test HTTP calls.

Creating proper examples is probably a good idea too, but idk if they can actually be run with cargo since the Worker needs to be executed by preview or edge worker runtime. Will put some more thought into this.

@jyn514
Copy link
Contributor

jyn514 commented Sep 2, 2021

Creating proper examples is probably a good idea too, but idk if they can actually be run with cargo since the Worker needs to be executed by preview or edge worker runtime.

This is an awful hack, but you could run wrangler dev from within the example and just have a standalone rust file next to it.

@ObsidianMinor
Copy link
Author

Maybe could add a lightweight testing framework around it like a Miniflare of sorts specifically for examples.

@nilslice
Copy link
Contributor

nilslice commented Sep 2, 2021

This is an awful hack, but you could run wrangler dev from within the example and just have a standalone rust file next to it.

You tried this? wrangler dev delegates to the build command, so we'd need a wrangler.toml somewhere, and it would expect to be able to use the custom build which relies on a bunch of preconditions to be true. I'd be surprised if this works, but pleasantly so :)

@nilslice
Copy link
Contributor

nilslice commented Sep 2, 2021

Maybe could add a lightweight testing framework around it like a Miniflare of sorts specifically for examples.

We could try something like that, but a soft-goal here is to not require users to have any JS tooling installed to use this. Or at least to prove it is possible.

@nilslice
Copy link
Contributor

nilslice commented Sep 3, 2021

This is now completed!

@nilslice nilslice closed this as completed Sep 3, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants