-
Notifications
You must be signed in to change notification settings - Fork 334
Module upload format + custom build commands + durable object support #1677
Conversation
4a42cb4
to
cc82568
Compare
441c591
to
34e3164
Compare
Is there a design doc somewhere? I don't know this codebase well enough to review the code but I'm interested to understand how this will end up looking from the user's perspective. |
And may I request an example of how to use a simple example like the |
@kentonv the only design doc was that google doc linked from our meeting on dec 9. I believe Matt's plan was to share an example wrangler template, which should hopefully make things clearer. It'll be at least a couple weeks before there's more progress on this PR though. |
@koeninger would you mind sharing the document? i'd like to take a look too |
Me too.
…On Tue, Dec 29, 2020 at 4:41 PM Sven Sauleau ***@***.***> wrote:
@koeninger <https://github.com/koeninger> would you mind sharing the
document? i'd like to take a look too
—
You are receiving this because your review was requested.
Reply to this email directly, view it on GitHub
<#1677 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAWSCDNYRI5244SSCSO5D4DSXJLLNANCNFSM4UXDVOQA>
.
|
src/settings/toml/builder.rs
Outdated
} | ||
|
||
fn build_dir() -> PathBuf { | ||
default_warning("build dir", BUILD_DIR); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's a little confusing to warn on build dir and src dir when they aren't actually used if upload_format is set to service-worker, right?
edit - looks like src_dir is used, but only for watch? It's still confusing that I can silence the warning by putting a nonexistent directory in there, and publish fine.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll address this when I address @ags799 concern below about having src/build dir be ./
, we don't want to allow that or allow nonexistent directories.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I ended up removing the default warning. I'll add a separate validation for the ./
and nonexistent directory cases
@@ -0,0 +1,66 @@ | |||
use std::env; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be really helpful to see an example TOML with the new additions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The new additions would look something like this for a durable object
[builder_config]
build_dir = "./build"
src_dir = "./"
upload_format = "modules"
[durable_objects]
implements = [
{ class_name = "Counter" }
]
or for a regular service worker just
[builder_config]
build_command = "./dummy-build.sh"
build_dir = "./my-build-dir"
src_dir = "./does-not-exist"
upload_format = "service-worker"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Lots of underscores and duplicate info... Perhaps it could be streamlined?
[build]
cwd = "."
command = "sh ./dummy-build.sh"
output = "./build"
format = "modules"
[durable_objects] # can't really avoid that one
implements = [{ class = "Counter" }]
I say this because toml is pretty flexible with how you can write out tables and while you may write a table like that, I may write it like
build.cwd = "."
build.command = "sh ./dummy-build.sh"
build.output = "./build"
build.format = "modules"
durable_objects.implements = [{ class = "Counter" }]
With the long names you get
builder_config.build_dir = "."
builder_config.build_command = "sh ./dummy-build.sh"
builder_config.src_dir = "./build"
builder_config.upload_format = "modules"
durable_objects.implements = [{ class_name = "Counter" }]
Toml accepts both but shorter names look better with the second format.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tend to prefer verbosity when it eliminates confusion, but I agree on build_command
-> command
.
I'll defer to @greg-mckeon on the rest
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like command
, and I think that src_dir
should be working_dir
. And I mentioned earlier that build_dir
should be upload_dir
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd personally want it to be configurable with reasonable defaults. So you can choose a different directory to watch, but it uses the build command's cwd by default, or perhaps just the root folder (where wrangler.toml is).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why are we talking about configuring cwd?
Wrangler won't work anywhere but the directory with wrangler.toml
If someone needs a different cwd for their build, they can change to it and back in their build script.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for explaining @xortive. I think src_dir
is good.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ah :/ I made the change to watch_dir already. It's easy to put it back, and I'm completely indifferent to which one we pick
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh that's fine idc either way.
Does it make sense to support a modules project without a build step? If I had a modules project with one source file at
I think we can solve this by moving I'll make a line comment about the |
We still need to know where to look for files to upload, right? Having to specify a subdirectory seems about as inconvenient / confusing as having to specify ignore patterns. I guess we could special case single file modules using the filename from package.json module, but that seems hacky |
move service_worker specific metadata to service_worker.rs
b86946b
to
1cf5fe6
Compare
going to open a new PR with just the durable object changes. will be merging the modules + toml-edit changes into a release branch for the rc |
…ate so format is preserved (#1745)
1cf5fe6
to
9265785
Compare
This lands support for `[wasm_modules]` as defined by cloudflare/wrangler-legacy#1677. wasm modules can be defined in service-worker format with configuration in wrangler.toml as - ``` [wasm modules] MYWASM = "./path/to/my-wasm.wasm" ``` The module will then be available as the global `MYWASM` inside your code. Note that this ONLY makes sense in service-worker format workers (for now). (In the future, we MAY enable wasm module imports in service-worker format (i.e. `import MYWASM from './path/to/my-wasm.wasm'`) and global imports inside modules format workers.)
This lands support for `[wasm_modules]` as defined by cloudflare/wrangler-legacy#1677. wasm modules can be defined in service-worker format with configuration in wrangler.toml as - ``` [wasm_modules] MYWASM = "./path/to/my-wasm.wasm" ``` The module will then be available as the global `MYWASM` inside your code. Note that this ONLY makes sense in service-worker format workers (for now). (In the future, we MAY enable wasm module imports in service-worker format (i.e. `import MYWASM from './path/to/my-wasm.wasm'`) and global imports inside modules format workers.)
This lands support for `[wasm_modules]` as defined by cloudflare/wrangler-legacy#1677. wasm modules can be defined in service-worker format with configuration in wrangler.toml as - ``` [wasm_modules] MYWASM = "./path/to/my-wasm.wasm" ``` The module will then be available as the global `MYWASM` inside your code. Note that this ONLY makes sense in service-worker format workers (for now). (In the future, we MAY enable wasm module imports in service-worker format (i.e. `import MYWASM from './path/to/my-wasm.wasm'`) and global imports inside modules format workers.)
This lands support for `[wasm_modules]` as defined by cloudflare/wrangler-legacy#1677. wasm modules can be defined in service-worker format with configuration in wrangler.toml as - ``` [wasm_modules] MYWASM = "./path/to/my-wasm.wasm" ``` The module will then be available as the global `MYWASM` inside your code. Note that this ONLY makes sense in service-worker format workers (for now). (In the future, we MAY enable wasm module imports in service-worker format (i.e. `import MYWASM from './path/to/my-wasm.wasm'`) and global imports inside modules format workers.)
This implements support for `[text_blobs]` as defined by cloudflare/wrangler-legacy#1677. Text blobs can be defined in service-worker format with configuration in `wrangler.toml` as - ``` [text_blobs] MYTEXT = "./path/to/my-text.file" ``` The content of the file will then be available as the global `MYTEXT` inside your code. Note that this ONLY makes sense in service-worker format workers (for now). Workers Sites now uses `[text_blobs]` internally. Previously, we were inlining the asset manifest into the worker itself, but we now attach the asset manifest to the uploaded worker. I also added an additional example of Workers Sites with a modules format worker.
This implements support for `[text_blobs]` as defined by cloudflare/wrangler-legacy#1677. Text blobs can be defined in service-worker format with configuration in `wrangler.toml` as - ``` [text_blobs] MYTEXT = "./path/to/my-text.file" ``` The content of the file will then be available as the global `MYTEXT` inside your code. Note that this ONLY makes sense in service-worker format workers (for now). Workers Sites now uses `[text_blobs]` internally. Previously, we were inlining the asset manifest into the worker itself, but we now attach the asset manifest to the uploaded worker. I also added an additional example of Workers Sites with a modules format worker.
This implements support for `[text_blobs]` as defined by cloudflare/wrangler-legacy#1677. Text blobs can be defined in service-worker format with configuration in `wrangler.toml` as - ``` [text_blobs] MYTEXT = "./path/to/my-text.file" ``` The content of the file will then be available as the global `MYTEXT` inside your code. Note that this ONLY makes sense in service-worker format workers (for now). Workers Sites now uses `[text_blobs]` internally. Previously, we were inlining the asset manifest into the worker itself, but we now attach the asset manifest to the uploaded worker. I also added an additional example of Workers Sites with a modules format worker.
This implements support for `[text_blobs]` as defined by cloudflare/wrangler-legacy#1677. Text blobs can be defined in service-worker format with configuration in `wrangler.toml` as - ``` [text_blobs] MYTEXT = "./path/to/my-text.file" ``` The content of the file will then be available as the global `MYTEXT` inside your code. Note that this ONLY makes sense in service-worker format workers (for now). Workers Sites now uses `[text_blobs]` internally. Previously, we were inlining the asset manifest into the worker itself, but we now attach the asset manifest to the uploaded worker. I also added an additional example of Workers Sites with a modules format worker.
JS projects with current config options will continue to work the same.
if a
[builder-config]
section is added, a custom build command can be configured. Wrangler will handle watching for changes and running the build command for the user.when the
script-format
field in[builder-config]
is set tomodules
, we should upload using the new modules format, uploading each file inbuilder-config.output_dir
as a module.The
main_module
is determined by looking at themodule
field inpackage.json
. this should point to the bundled module in the output directory.for
service-worker
builds, the behavior is the same as always: themain
field inpackage.json
is what will be uploaded, so this should be the output of your build tool.This PR closes a lot of tickets with the same general theme (I hit xyz build edge case and I need a new feature to fix it/I want to use newer webpack version/I don't want to use webpack) that all come down to the limitations of wrangler's current build setup. Custom builds will allow users to setup their own build step, which wrangler will upload the results of unmodified to the API.
closes #206
closes #820
closes #954
partially addresses #1102
closes #1397 (just make custom build script)
closes #1550
closes #1557
closes #1558