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

perf(worker-rust): Add dev env for faster local build times #5059

Merged
merged 3 commits into from
Mar 8, 2024

Conversation

futile
Copy link
Contributor

@futile futile commented Feb 20, 2024

What this PR solves / how to test:

Add a dev-environment to wrangler.toml which builds with worker-build --dev instead of worker-build --release.
This makes build times for local development much faster.

Add opt-level = "s" to Cargo.toml so release builds are optimized for size.

Remove the deprecated --local parameter from the wrangler invocation.

Author has addressed the following:

Not sure which of these I should do (and how).

  • Tests
    • Included
    • Not necessary because: basic configuration change in a template
  • Changeset (Changeset guidelines)
    • Included
    • Not necessary because: we don't have changesets for templates??
  • Associated docs
    • Issue(s)/PR(s): do we need to update some docs??
    • Not necessary because:

@futile futile requested a review from a team as a code owner February 20, 2024 12:11
Copy link

changeset-bot bot commented Feb 20, 2024

⚠️ No Changeset found

Latest commit: 75114c5

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

Copy link
Contributor

A wrangler prerelease is available for testing. You can install this latest build in your project with:

npm install --save-dev https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/7973227046/npm-package-wrangler-5059

You can reference the automatically updated head of this PR with:

npm install --save-dev https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/prs/5059/npm-package-wrangler-5059

Or you can use npx with this latest build directly:

npx https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/7973227046/npm-package-wrangler-5059 dev path/to/script.js
Additional artifacts:
npx https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/7973227046/npm-package-create-cloudflare-5059 --no-auto-update
npm install https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/7973227046/npm-package-cloudflare-kv-asset-handler-5059
npm install https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/7973227046/npm-package-miniflare-5059
npm install https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/7973227046/npm-package-cloudflare-pages-shared-5059
npm install https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/7973227046/npm-package-cloudflare-vitest-pool-workers-5059

Note that these links will no longer work once the GitHub Actions artifact expires.


wrangler@3.28.3 includes the following runtime dependencies:

Package Constraint Resolved
miniflare workspace:* 3.20240129.3
workerd 1.20240129.0 1.20240129.0
workerd --version 1.20240129.0 2024-01-29

Please ensure constraints are pinned, and miniflare/workerd minor versions match.

Copy link

codecov bot commented Feb 20, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 70.38%. Comparing base (01e0846) to head (75114c5).
Report is 48 commits behind head on main.

Additional details and impacted files

Impacted file tree graph

@@            Coverage Diff             @@
##             main    #5059      +/-   ##
==========================================
+ Coverage   70.34%   70.38%   +0.04%     
==========================================
  Files         298      298              
  Lines       15463    15463              
  Branches     3966     3966              
==========================================
+ Hits        10877    10884       +7     
+ Misses       4586     4579       -7     

see 6 files with indirect coverage changes

Copy link
Contributor

@petebacondarwin petebacondarwin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Copy link
Contributor

@petebacondarwin petebacondarwin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@futile
Copy link
Contributor Author

futile commented Feb 26, 2024

Thanks for the review! One thing I'm not sure about: Removing the --local flag. This might fail with older wrangler-versions now, I think? Should I remove it again from this PR?

But then again, this template will probably be used with more recent versions of wrangler (since a template is usually used for new projects), so it might just be fine in this case.

@Skye-31
Copy link
Contributor

Skye-31 commented Feb 26, 2024

Wrangler 3, when the change to default to local mode occurred, has been out for ~9 months, so personally I wouldn't be too concerned about the change

@futile
Copy link
Contributor Author

futile commented Feb 26, 2024

Awesome, thanks! :)

@petebacondarwin
Copy link
Contributor

Do we need to update some docs somewhere to match this change?

@futile
Copy link
Contributor Author

futile commented Feb 26, 2024

One other point I realized: Is opt-level = "s" for release-builds desired by default? Since it won't be running in the frontend/not downloaded by browsers, maybe this doesn't actually make that much sense?

I added it originally because it's a very common optimization for wasm use-cases, but maybe that doesn't really count for workers.

@lrapoport-cf lrapoport-cf added the awaiting Cloudflare response Awaiting response from workers-sdk maintainer team label Mar 5, 2024
@petebacondarwin
Copy link
Contributor

I'm no Rust specialist so I would bow to your (or anyone else's views) but I would note that Workers still have a size limit on what can be deployed. So it might be worth keeping a size optimisation turned on?

@futile
Copy link
Contributor Author

futile commented Mar 7, 2024

I'm no Rust specialist so I would bow to your (or anyone else's views) but I would note that Workers still have a size limit on what can be deployed. So it might be worth keeping a size optimisation turned on?

That's a good point. I think optimizing for size by default should be sensible for wasm-builds (like in this case), and users can still change/adapt this later on anyways.

So if it's up to me I would keep the opt-level = "s", but feel free to let me know if I should change it :)

@Skye-31
Copy link
Contributor

Skye-31 commented Mar 7, 2024

That seems reasonable to keep IMO

@petebacondarwin petebacondarwin merged commit 2a35697 into cloudflare:main Mar 8, 2024
22 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
awaiting Cloudflare response Awaiting response from workers-sdk maintainer team
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants