Let wrangler support development in Deno
Deno makes it possible to run ES6 modules in a secure way on the server and share exactly the same code with the browser, so its only natural to use the same code in your cloud workers.
Deno is a rust crate, so the smooth way to integrate would be to include that in wrangler directly.
I suggest letting wrangler.toml have type = "deno" and when type is set to deno it will look for module=... where the ... will be a relative path or url to the starting point.
This approach even makes it possible to load scripts directly from a git repo with only the wrangler.toml - making automation super smooth. It will also give wrangler an integrated way of supporting typescript development (super helpful when looking at the challenging debugging for cloud workers as simple things like spell errors are pointed out upfront).
wrangler.toml
type = "deno"
module= "./mod.ts"
wrangler.toml:
type = "deno"
module= "https://raw.githubusercontent.com/mygithubname/cool-repo/master/index.js"
I'm not very familiar with deno. From what I understand, it is a completely different runtime than both node and Cloudflare Workers. My guess would be that deno is not compatible, unless there is some way to transpile deno code to vanilla JavaScript for the Workers runtime. What do you think?
It's a different runtime, we will need to transpile it to JS or compile it to Wasm and emulate system APIs.
It will also give wrangler an integrated way of supporting typescript development (super helpful when looking at the challenging debugging for cloud workers as simple things like spell errors are pointed out upfront).
@mathiasrw have you seen the typescript template for wrangler/Cloudflare Workers?
Getting started is as simple as:
wrangler generate my-ts-project https://github.com/EverlastingBugstopper/worker-typescript-template
I personally only use TypeScript for Workers projects.
Thank you for your inputs. A few comments:
I'm not very familiar with Deno. From what I understand, it is a completely different runtime than both node and Cloudflare Workers. My guess would be that Deno is not compatible unless there is some way to transpile Deno code to vanilla JavaScript for the Workers runtime.
Deno is "just" a way of running javascript code in V8. The nice thing about them is that the building of the final plain javascript can be done from es6 code with full references to imported es modules - so the code works in all modern browser and in Deno. Think of it as Node that would be 100% compatible with the browser.
It's a different runtime, we will need to transpile it to JS or compile it to Wasm and emulate system APIs.
There is no system APIs needed to be emulated as this does not make sense (just like you can't access the fs module just because you are building from code used in Node). Deno spits out pure javascript that can be run in a browser.
The whole idea would be to use the rust crate to call a single function and get the vanilla javascript back that wrangler can then process as anything else.
@mathiasrw have you seen the typescript template for wrangler/Cloudflare Workers?
I have. Thank you. It's not that typescript cant be used at the moment but Deno offers a much more rich developer experience.
I guess ill leave it for now, but the request is still there. I'll leave it open for now to see if more people are interested.
@xtuc @EverlastingBugstopper Technically we wouldn't need to implement Deno's API to support "Deno development". I believe what this is proposing is we support Deno as a bundler which allows us to have easy TypeScript support and the remote package management Deno is known for. It may be better for us to support general bundlers though so we're not explicitly supporting every bundler we come across and instead we just ask users to plug in their own like Deno or webpack or whatever.
It depends what Deno as a bundler targets.
users to plug in their own like Deno or webpack or whatever
yeah that's something I have in mind for some time. You can emulate it using the wranlger type: javascript, but we need a tool that ensures the output is compatible with our runtime and create bindinds etc
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
This issue has been automatically closed because it has not had recent activity. You may re-open the issue if it is still relevant.
Most helpful comment
@xtuc @EverlastingBugstopper Technically we wouldn't need to implement Deno's API to support "Deno development". I believe what this is proposing is we support Deno as a bundler which allows us to have easy TypeScript support and the remote package management Deno is known for. It may be better for us to support general bundlers though so we're not explicitly supporting every bundler we come across and instead we just ask users to plug in their own like Deno or webpack or whatever.