integrate module resolution in `vite-plugin-cloudflare`

[dario-piotrowicz]

integrate the module resolution solution implemented in @flarelabs-net/vite-environment-provider-cloudflare in the new vite-plugin-cloudflare package

also add the module-resolution tests that were present in the old repository here too

[dario-piotrowicz]

One general stylistic point is that I prefer to avoid explicit return types if possible. I feel that most of the time it's better to just let the type system do it's job. By providing return types you can also inadvertently widen the type.

this is exactly the opposite of my preference 😅

I think pretty much everyone agrees that relying on the type system automatically inferring types is the way to go, but when it comes to return types I feel like having the extra explicitly is actually quite good since there you can convey intent and let typescript (and other developers) know what you want your function to do (by having ts automatically infer the return type you lose a certain degree of control, and the code saved is negligibile IMO)

that's my personal view, but anyways I'm fine with going with whatever the team prefers 👍

[jamesopstad]

One general stylistic point is that I prefer to avoid explicit return types if possible. I feel that most of the time it's better to just let the type system do it's job. By providing return types you can also inadvertently widen the type.

this is exactly the opposite of my preference 😅

I think pretty much everyone agrees that relying on the type system automatically inferring types is the way to go, but when it comes to return types I feel like having the extra explicitly is actually quite good since there you can convey intent and let typescript (and other developers) know what you want your function to do (by having ts automatically infer the return type you lose a certain degree of control, and the code saved is negligibile IMO)

that's my personal view, but anyways I'm fine with going with whatever the team prefers 👍

Haha. Yeah, I had feeling we would disagree about this one. You may well be right and it's also probably a bit dependent on the context. Let's not worry about it in this PR anyway.

[vicb]

Sorry for a not really helpful comment but some comments on what I have read here:

• I do prefer explicit return type - that with a good function + param names allow to skip having to read the fn body
• +10 for a common eslint/prettier style that we would share across projects

I was thinking starting on a common style at the end of this week.

A few things I'd like to include is import sorting, force curly braces, ...

I have opinions about code style but very few are strong and that's something we should discuss. Generally I like to stick to something "common" and avoid exotic settings. Also I prefer to see things that I wouldn't pick at first but at least are consistent across projects.