One function I've written that I frequently use is a generic iterate <T> function which (in JS/TS land) allows you to loop over a T[], Array<T>, ArrayLike<T>, Iterable<T>, AsyncIterable<T>, including generators and async generators.
It is just easier to always be able to write: "for await (const item of iterate(iterable))" in most places, without worrying about the type of the item I am looping over.
I like the reducers and collectors in your library! Going to try it out.
Also, something new I discovered is the Array.fromAsync() method in JS, which is like Array.from() but for async values. I don't think it is available in all browsers/runtimes yet though.
I wanted to expand and say that if you are keen on writing and managing infra and running it yourself, besides Serverless Framework, SST, CDK, arc.codes, and Terraform are all good options.
We’re building https://rx.run so you don’t have to think about these sorts of things and can just ship your app.
If you can write a function, you can deploy to the cloud. No infra or deployments to configure or manage. Storage, auth, payments, and more are all built right in.
Currently in beta and TypeScript only but support for all mainstream languages coming soon.
You could also add a collapse toggle ">" to the classname line that will open the focus view (instead of the keyboard toggle). I think the VSCode API supports it.
We're giving away free hosted Raspberry Pis for the first ~X :) users that sign up for the https://rx.run beta.
rx is a lightweight CLI and runtime that lets you deploy any function instantly as you save it in your editor. It’s fast, simple, and takes care of setting up all your cloud infrastructure.
Currently I personally host ~20 or so web and scheduled applications on a Raspberry Pi. It just runs in a closet, has a fan on it to keep it cool, and is super fast. I basically never check on it. It is locked down for security, has scripts to automatically run services on restart, and to keep stuff updated.
Way better than dealing with EC2 or Lambda. Lets me ship stuff fast, THEN I can think about scaling later and paying for expensive cloud services and databases (after ACTUALLY having users).
I want more people to experience this! You don't need cloud and microservices and Kubernetes (come on) for everything.
I just tested with yarn, and the same issue exists unless the yarn or npm config option for `script-shell` is set to zsh (like the solution described in the link).
With `script-shell` set to zsh: globstar paths work with subdirectories.
Without `script-shell` set (the default on linux): only top-level paths work.
The command I ran was `yarn test` with this test script in the scripts section of package.json: `node --test src/**/*.test.ts`.
I don't want to turn this into a GitHub issue thread, but also didn't want to be dismissive. I hope that helps.
I'm reporting this here for awareness. Please check your CI pipelines for any issues.
TLDR:
Fixing the issue with globstar paths (`**/*`) not working when running an npm script:
`npm` uses `sh` by default on Linux when running a script with `npm run`. The thing is, if you are using globstar paths in your script, like `node --test src/**/*.test.js`, paths that are more than one-directory-level deep won't be expanded!
This is not an issue with Node.js or npm per say, but with how `sh` works by default. The thing is, this isn't the behavior that most people _expecting_ when setting up their npm scripts.
The link in this submission includes a description of this "pitfall", a resolution for Linux, and some other notes.
I strongly recommend checking your important repositories and CI pipelines for any issues, like tests getting skipped or assets not getting bundled (since their globstar paths are not being picked up by `sh`). Basically just check for any `package.json` that has `**/*` in it. You may also want to check that all your other scripts are being run with bash (with the `shopt globstar` setting set to `on` -- or just use `zsh`).
Sorry for the drama -- but I just _KNOW_ that this is being overlooked all over the place.
Also, the current theme I'm seeing across many companies is "we have added lots of engineers/products/vendors and we need to focus on building a platform (infra, automation) that lets us ship and not get in the way".
It seems industry went from un-bundling engineers --> sre, devops, network, security, developers --> re-bundling much of this knowledge back into a new role/practice area called "platform engineering".
I just dug a bit deeper as I couldn't remember the differences. They're not referring to the same things.
"alwaysStrict", which adds "use strict", is different than TypeScript "strict" mode, which constrains the language.
Setting "strict" to "true" enables "alwaysStrict", but not the other way around. I'd remove "alwaysStrict" and go with "strict" as it covers more things.
One function I've written that I frequently use is a generic iterate <T> function which (in JS/TS land) allows you to loop over a T[], Array<T>, ArrayLike<T>, Iterable<T>, AsyncIterable<T>, including generators and async generators.
It is just easier to always be able to write: "for await (const item of iterate(iterable))" in most places, without worrying about the type of the item I am looping over.
I like the reducers and collectors in your library! Going to try it out.
Also, something new I discovered is the Array.fromAsync() method in JS, which is like Array.from() but for async values. I don't think it is available in all browsers/runtimes yet though.