-
Notifications
You must be signed in to change notification settings - Fork 337
Don’t infer project type from the template name #315
Comments
We can just include a mostly-empty wrangler.toml that has |
ProblemWhen creating a new project with Proposed solutionThere’s not really an easy way to infer the type from the template unless there is something in the template itself that hints at what In our templates, we can provide a mostly empty Required changesThis will require PRs to add a Open questions
|
scoping: implementing the proposed solution will involve writing logic to alter an existing wrangler.toml in order to add the project name. |
Could you explain what you mean by that/why? I don’t think this solution requires any changes to the .toml itself. |
during the generate phase, wrangler actually generates a toml on behalf of the user, and it uses the name argument passed by the user for the project name field. so if you run |
Serde should handle this for us -- we serialize the config, change it, then deserialize |
Ah! I understand now :) Awesome. @granjef3’s comment makes sense. serde is pretty magic + what we use to write to the |
We could also use Ashley’s cargo generate crate (which we already use) to
fill in the project name since it has templating support.
…On Fri, Jul 12, 2019 at 9:39 AM Avery Harnish ***@***.***> wrote:
Ah! I understand now :) Awesome. @granjef3 <https://github.com/granjef3>’s
comment makes sense. serde is pretty magic + what we use to write to the
.toml currently. Should be fairly easy to include that. I’ll edit my
proposed solution
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#315>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAEKLUPBUA5VUYCFZP5GIHDP7CJQ7ANCNFSM4H7IPCFA>
.
|
Work that needs to be done
Open questions: How should wrangler handle generate commands where a template without a type field in |
this is dependent on updating all the templates above; may not make it in 1.3.0. It may also be wise to let the Environments milestone soak for a bit before implementing this change. |
Currently in the docs, we suggest that people run
wrangler generate myApp https://github.com/cloudflare/rustwasm-worker-template
to generate our default rust app. This works because there is a code section that checks to see ifrust
is in the name of the template, and if it is, it will assume the user wants a project withtype=rust
. This assumption is shaky and has led to some code sections that are hard to read.We should stop inferring the project type from the name and either infer from the project structure itself, or require a type to be passed when generating a new project.
There’s a PR for this here: #314 but it breaks one of the commands we suggest on our docs page:
wrangler generate myApp https://github.com/cloudflare/rustwasm-worker-template
The reason it breaks is because without a specified type, it defaults to webpack, and our build process makes assumptions about where to look for the javascript, so it can’t build the project w/o the type being set to
rust
.This change does work however if you simply run
wrangler generate —type rust
and is also more succinct than what we currently have in our docsBlocked by #313 as it makes changes to this particular section of code
The text was updated successfully, but these errors were encountered: