uppercase methods — export function GET, etc

[Rich-Harris]

Update:

• issue: Uppercase handler names (export function GET() {...} etc) #5367
• PR: feat: uppercase endpoint methods #5513

---

I had innocently gone through life believing that uppercase HTTP methods were a mere convention until #5354 led me to whatwg/fetch#50. Now I know better — PATCH and patch are not the same.

Which makes me wonder if we should make our endpoints more HTTP-ish:

export function GET({ params }) {...}
export function POST({ params, request }) {...}
export function PATCH({ params, request }) {...}
export function DELETE({ params }) {...}

function send(...){...}

Couple of things to point out about this:

• The exported handlers are very clearly differentiated from utility functions like send
• We don't need to have a special rule that DELETE handlers are called del instead of delete, since whereas delete is a keyword in JavaScript, DELETE is not. I loathe this aspect of our design; it almost made me want to have a default export with handlers as properties instead of exporting named functions, despite the useless extra level of indentation it would force
• minor bonus: get is a fairly common function/method name (often paired with a set); in this world, handlers are very easy to search for in a codebase

On the other hand:

• it would be a mildly annoying breaking change
• some people might not like the aesthetics

WDYT?

[kevmodrome]

Yes! Go go go!

[ghost]

I honestly don't like the aesthetics either but if that's the only minor gripe then the benefits still outweigh the fact that it's a breaking change imho because after all Svelte Kit is still in beta and it would be easy to migrate to the new naming convention.

[stephane-vanraes]

Migrating is a simple "Find and Replace", so not devastating.

[rchrdnsh]

How do I do that? Across all files, I mean...the error message does not tell me where the 'get' is in any file...

[rchrdnsh]

I seem to have found them by manually looking through every file I could think of, but is there a way to look through all files at the same time to save time and hassle and headache?

[geball]

@rchrdnsh To look through your files, you could cd into your project and use grep (run some variation of grep -rn --exclude-dir node_modules --exclude-dir '.svelte-kit' 'get(' .) or install ripgrep and run something like rg 'get\('. There are several ways you could approach changing them, including sed, which is explained well on this SO question. If you're using an editor like VS Code, there's a global find and replace that you could use.

[utunga]

this one is driving me nuts on an unfamiliar code base so just to say not a 'simple find and replace' at all.

[nusendra]

Thanks @geball

[mattjennings]

Definitely in favour of this even just to get rid of the del weirdness. Uppercase methods in this context make sense to me.

[Mlocik97]

for me upper-case names in JS evoke they are constants in global scope, not really like it from this point of view, but on other hand it looks like more HTTP-ish. Even tho, I would maybe like to use upper-cased name as string:

export default {
    'GET': ({ params }) => {
          return {};
    }
}

looks interesting, except as you said, that intendation level. Hmm, maybe I would let it be named exports, it also makes more sense for me, as I export only some handlers, not all of them.

[ramiroaisen]

Just my 2 cents here, I really don't like the verbs in uppercase, uppercase in js is for constants

[vpanyushenko]

I think this is a good change for all of the above listed reasons. Many documentation sites use uppercase letters; for example, the Mozilla docs use all uppercase verbs for the method property: https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/Using_Fetch#supplying_request_options

[mustofa-id]

it would be nice if we could use both.

[sillvva]

I prefer the uppercase methods from a DX standpoint, since it matches the known convention for HTTP methods.

[stordahl]

I do agree and think this will help new Svelte devs adopt endpoints, if they're already familiar with HTTP generally

[kvetoslavnovak]

👍🏼

[lailton]

Looks good and make totally sense. 👍🏻

[michaelusantiago]

And what are the types(ript) of paramaters on functions? like in load() ?
export async function load({ url }) { ... } ? Some of my codes causes (typescript) errors after I change to vite(d).
some are improved though, before my links don't work as expected as in menu when anchoring back to home, but in vite it works, that's why I changed update it but have some typescript errors.

[michaelusantiago]

I changed http methods to uppercase and I am getting this error
TypeError: disturbed at Request.blob (file:///D:/JavaScript/2021/Node/Project/NPOS/website/node_modules/@sveltejs/kit/dist/node/polyfills.js:2802:20) at Request.text (file:///D:/JavaScript/2021/Node/Project/NPOS/website/node_modules/@sveltejs/kit/dist/node/polyfills.js:2835:32) at Request.json (file:///D:/JavaScript/2021/Node/Project/NPOS/website/node_modules/@sveltejs/kit/dist/node/polyfills.js:2844:37) at POST (D:\JavaScript\2021\Node\Project\NPOS\website\src\routes\api\v1\clients\login.ts:18:39) at runMicrotasks (<anonymous>) at processTicksAndRejections (node:internal/process/task_queues:96:5) at async render_endpoint (file:///D:/JavaScript/2021/Node/Project/NPOS/website/.svelte-kit/runtime/server/index.js:260:19) at async resolve (file:///D:/JavaScript/2021/Node/Project/NPOS/website/.svelte-kit/runtime/server/index.js:3434:11) at async Object.handle (/D:\JavaScript\2021\Node\Project\NPOS\website\src\hooks.ts:17:10) at async respond (file:///D:/JavaScript/2021/Node/Project/NPOS/website/.svelte-kit/runtime/server/index.js:3379:20)

[stephane-vanraes]

@michaelusantiago
From the error it looks like you are doing both a .text() and a .json(), that does not work as you can only use the body once (this is a web spec thing, not a svelte thing).

In the future, try to use other channels like discord for support questions and not add to discussions.

[michaelusantiago]

thank you. I fixed my error.

[utunga]

Wow this is really annoying breaking change without any particular good reason. "it would be a mildly annoying breaking change". No! Surely you know that the downstream effects might be more than you imagine. People that are dealing with largish unfamiliar code bases and the many many different ways you can syntatically write the concept "export function get(" coupled with the fact that - as you say - "get" is incredibly common method name across a large number of contexts even "get(" is very common. It is not at all easy to find.

If this was needed for some reason, fine. But just because it seemed like a nice jape. Ugh.

PS in the middle of (failing to) get someone elses app building because of this stupid breaking change I guess I'll just downgrade sveltekit

[Mlocik97]

SvelteKit is still beta, so breaking changes are expected... it was done at same time as bigger breaking change (Vite 3), and so if updating, you would still need to fix app. But this one change is so simple, that you need to just replace get, post, put, patch, del for GET, POST, PUT, PATCH, DELETE,... that can be done with IDE's feature find and replace in seconds... you just replace these in all files in ./src/routes/ that ends with .js or .ts extension. To make it side-effect free, you actually replace get( for GET( and so on. It's easy change doable in seconds.

so even if you have 2000 endpoints, it doesn't matter, it will be done with IDE automatically..

[niktek]

For those in typescript land, you will also want to do a search for get: or get : when it has been used as export const get: RequestHandler<OutputType> =... etc.

[utunga]

PPPS I worked out that in my case it was actually simpler than I thought. That the cause of the problem was at other levels of the compilation process. But the problem is when you have an obscure error deep in the stack and the error message points out this concern and then you go to change it and it doesn't fix it.. well you don't actually know why it isn't working.

I hear the point that this is in beta. So mostly I am withdrawing my concern.

That said I was porting an app that was already in production so.. yeah. If the core maintainers could just be aware that when you change things at a lower level it can be a lot harder to fix for others than it is for you. You already have a comprehensive understanding of what's going on and a fully working build etc so what is genuinely just 'a simple find and replace' a five-minute job to you because it's on an actively maintained/current code base in which you are familiar - it can be a lot lot harder for others downstream because they're missing all that tooling and context. That said it was only about a half day or so of messing around before I figured out what I needed to change and where to update to this version. And it felt like that was a worthwhile use of my time given the importance of having methods in UPPERCASE() (violating most coding guidelines but it looks nice) instead of lowercase().

[nicopolyptic]

Couldn't you have just added a non-breaking option instead of coupling case-sensitive function name to HTTP methods?