The code contains just the following, I made this on purpose to validate the assumption, and it fails with the above exception.

import { Client } from "@notionhq/client"

export async function onRequestPost(context) {
  const notion = new Client({ auth: context.env.NOTION_INTERNAL_INTEGRATION_TOKEN })
}

Prior to that I ditched the package and used plain JS + fetch to work with API, but I need packages for more complex tasks where I can't implement in plain JS due to time constraints.

the issue is with

node-fetch

usage in the notion client.

node-fetch

is not made for use with cloudflare workers. it's also unnecessary since fetch support is built in to the worker environment. you can pass in your own fetch implementation to the client (https://github.com/makenotion/notion-sdk-js/blob/02ad37d949bed482d63a36cd9408f8a3c222bccf/src/Client.ts#L124). that'll get you halfway there. the other half would involve either preventing

node-fetch

from resolving and muffling the error or resolving it to a noop. you can do this one of several ways: 1. bundle the worker yourself and do the aliasing in the bundler config 2. alias the module with your node package manager if it supports it (i.e. yarn resolutions, pnpm as well probably?)

i suppose you could also fork the client or dump all the code into your project and remove

node-fetch

. if you're really pressed for time that would certainly do the trick.

an aside: it'd be kinda neat if wrangler auto-aliased common polyfills like

node-fetch

. the API differences are negligible: - https://github.com/node-fetch/node-fetch/blob/HEAD/docs/v2-LIMITS.md - https://github.com/node-fetch/node-fetch/blob/HEAD/docs/v3-LIMITS.md

Does Functions file-based routing also have the option to use a flat routes file system convention, i.e. similar to what Remix has added? See: https://github.com/remix-run/remix/discussions/4482 and https://remix.run/docs/en/main/file-conventions/route-files-v2

It does not, but sounds like an interesting feature addition!

Perhaps it could make sense to file this on the wrangler repo for further discussion?

No worries! I'll put together a feature request

Do workers have an inbuilt router? Sorta similar to this: https://medium.com/deno-the-complete-reference/native-router-in-deno-16595970daae

That's not really a native router. URLPattern is a web standard and it's supported on Cloudflare (unlike node.js which Deno competes). So, you can probably run the router they built in that article inside of a Worker or Durable Object... or Functions if you use advanced mode.

That said, I'm under the impression that the router in Hono is faster than native URLPattern.

Yeah I noticed that ended up just using the URLPattern API https://blog-cloudflare-com.webpkgcache.com/doc/-/s/blog.cloudflare.com/introducing-the-wintercg/

I'll have to check that out, I just wanted to do something quickly without wrangler/npm, that's the beauty of deno and importing packages from URL's

Another idea, you could set up a catch-all route with Functions using

/custom-router/[[route]]

while still using other standard file-based routes

/api

,

/api/login

, etc. Then inside that

/custom-router

onRequest

handler you could use the code from that "Native [not] Router".

Note too that while there may be some slight differences in speed between modern routers, in most cases, you should worry about optimising your own code more than which router is 1% faster.

Very true.

Pico uses URLPattern under the hood - but Hono has more features

Pico is the super-small Hono, also by Yusuke

anyone have tips for building typescript to an advanced-mode function? I assume CF would refuse access to

/_worker.js

, so I want to bundle everything in that file so none of the backend code is exposed publicly

I'm also currently fighting with

tsc

, as it looks like the types for the Node compatibility APIs are not included in

@cloudflare/workers-types

Wrangler uses

esbuild

and marks the

node:

modules as external

Not too sure on how you can achieve the same with

tsc

though

I believe they should be on the later versions - which do you have?

should be the latest version of everything - in my package.json:

"@cloudflare/workers-types": "^4.20230321.0",

Oh I know why

Workers types is behavioural based on the compat date/flag you choose

but you can't specify a way of including nodejs compat, because it doesn't have a compat date

in the settings for the pages application?

I can specify the

nodejs_compat

flag in the pages settings, but that doesn't change anything about the installed npm package where

tsc

is getting the type declarations

No, you choose it in your tsconfig - types are nothing to do with your project settings. For example, if you have

json
"types": ["@cloudflare/workers-types/2022-08-04"]

Then you'll get workers types for the compat date of 2022-08-04