Well yes, that's the sane way anyone would reach for first, but that's clearly not new-age enough by Vercel's standards, so here we are. Similar to the other magic string interactions, all of this is a roundabout way of introducing platform lock-in.
The problem with higher-order functions is that you can't guarantee that your static analysis is correct, and you end up with functions that look like functions but don't behave like functions.
It's similar to the problem that `require` had in browsers, and the reason that the `import` syntax was chosen instead. In NodeJS. `require` is just a normal function, so I can do anything with it that I could do with a normal function, like reassigning it or wrapping it or overwriting it or whatever. But in browsers (and in bundlers), all imports need to be statically known before executing the program, so we need to search for all calls to `require` statically. This doesn't work in JavaScript - there are just too many ways to dynamically call a function with arguments that are unknown at runtime or in such a way that the calling code is obscured.
That's why the `import` syntax was introduced as an alternative to `require` that had rules that made it statically analysable.
You'd end up with a similar situation here. You want to know statically which functions are being decorated, but JavaScript is a deeply dynamic language. So either you end up having a magic macro-like function that can only be called in certain places and gets transpiled out of the code so it doesn't appear at runtime, or you have a real function but you recognise that you won't be able to statically find all uses of that function and will need to set down certain rules about what uses can do with that function.
Either way, you're going to be doing some magic metaprogramming that the developer needs to be aware of. The benefit of the "use X" syntax is that it looks more magical, and therefore better indicates to the reader that magic is happening in this place. Although I agree that it's not my personal preference.
The container opens a gateway and each container provides its own local IP (e.g. 192.168.64.2), from what I understood, every services known host machine and can communicate with each other.
On my current implementation, I didn't work with DNS/Network Resolution because I need to understand better what I can/can't do with the API Apple provides, so the only things it does is handling the port mapping using `socat`, as the docs recommends.
> Any reason why don’t implement this as a plugin for the container CLI?
I did a different CLI because, considering that Apple released their v0.1.0, I'm not sure if they're working in some kind of official support for compose YAMLs.
With that in mind, I tried to avoid coupling it into the container CLI, to avoid injecting any kind of breaking change or something else which could cause any issue in the future.
To be honest, I'm not sure why they didn't already release it supporting a compose-like tool. But my hypothesis is that considering they release a v0.1.0, they tried to be lean on their CLI and maybe they're building something on top of it.
If there's someone like me that maintains a feed with RSS feed, maybe you know that YouTube brings a feed RSS for every channel, but it's boring to get it.
Being a lazy person, I wrote a simple website that does all the job, you just need to insert the YouTue channel URL.
