feat: --no-build

[threepointone]

This adds a --no-build flag to wrangler publish and wrangler dev. We've had a bunch of people asking to be able to upload a worker directly, without any modifications. While there are tradeoffs to this approach (any linked modules etc won't work), we understand that people who need this functionality are aware of it (and the usecases that have presented themselves all seem to match this).

---

Disable whitespace changes for this review!

[changeset-bot]

🦋 Changeset detected

Latest commit: 3c58ea4

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
wrangler	Patch

Not sure what this means? Click here to learn what changesets are.

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

[github-actions]

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

npm install --save-dev https://prerelease-registry.developers.workers.dev/runs/2576137124/npm-package-wrangler-1300

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

npm install --save-dev https://prerelease-registry.developers.workers.dev/prs/1300/npm-package-wrangler-1300

Or you can use npx with this latest build directly:

npx https://prerelease-registry.developers.workers.dev/runs/2576137124/npm-package-wrangler-1300 dev path/to/script.js

[Erisa]

Hi,

I like this functionality. I have some workers that are just a simple javascript file and I like having them uploaded as-is.

My question though is, would it be possible for this to be a wrangler.toml option? With wrangler 1 I'm currently using type = javascript which makes it do a similar thing and understandably was removed for wrangler 2. What I'm envisioning is something like nobuild = true and then main file is used directly and never built or modified.

One of the struggles I came across as well as the file being built unnecessarily before upload was using wrangler dev since it spat out line numbers in errors that didn't mean anything relative to my source. I understand there are probably source map setups that can restore this but my feeling when it's a single javascript file is that it should just be left alone.
And this proposal seemingly wouldn't solve that since it looks like its only for publish?

Thanks!

[threepointone]

This is exactly the kind of feedback I was looking for, thank you very much! We could probably do it for dev as well, as well as being able to specify it in wrangler.toml.

[Erisa]

Sounds good!

[threepointone]

I've renamed it to --no-build, and added it for wrangler dev as well. I'm going to hold back on adding it to wrangler.toml so we can try this out for a bit before doing so, and then I'll put it in a future PR.

Opened this up for review.

[rozenmd]

lolwtf

[threepointone]

computers sigh

[rozenmd]

Looks good to me, just some merge conflicts

[threepointone]

"no build" is actually a bad name for this flag, since "build" refers to custom builds, and this would imply that it wouldn't run custom builds. Will change this to a different name before releasing today. Open to suggestions. no-bundle? raw-publish?

[Erisa]

Of those two, I prefer no-bundle. It's more clear about what's actually happening when it's used. The idea of a "raw publish" feels less obvious and more ambiguous.

I also don't have a better idea myself.

[petebacondarwin]

custom-only? I think no-bundle sounds best.

[threepointone]

Aight, let's go with --no-bundle. I'll put up a PR asap

[threepointone]

#1399

[wuservices]

I had been following his, hoping for an actual --no-build, and it's definitely clearer now that it's called --no-bundle.

However, what if I really wanted --no-build? How can I just upload the main file and skip the build command?

My reasons basically mirror what's in cloudflare/wrangler-legacy#2219. I have CI building and testing from an existing webpack build, and for efficiency and consistency, I want to treat my built JavaScript as an "immutable" artifact that I can deploy as is. This is especially important as I redeploy the same script across multiple environments and because build inputs like environment variables could change the contents of our built script.

[threepointone]

@wuservices we're separately working on "versioning" which should (theoretically) let you do reverts to a previously deployed version. I think that would be a proper solution here, instead of a "no-build" solution. Alternately, as we're building a first class api to manipulate wrangler, you may be able to wire this up yourself on the future.

[threepointone]

Of course, another option is to not use the [build] field, and just manually run your build step yourself before running publish/dev.

[wuservices]

@threepointone the ability to revert could certainly be helpful, but it wouldn't fit into our current TeamCity CI workflow as naturally as being able to retrigger a previous deployment that completed successfully. That's workable though. However, if you had multiple separate environments (or zones or accounts), versioning wouldn't allow you to deploy the exact same code everywhere.

However, it sounds like getting creative to avoid the [build] field could definitely work, even if this falls a bit outside the expected usage! Thanks for the idea.