khalidx

Recommend partial download support and resume, otherwise this will burn through whatever mechanism is caching and serving the models if people navigate away from the page mid-download.

Finally!

So happy to see support for running durable objects outside of one provider. Upvoted.

The "durable object" concept has been repeatably demonstrated to be a valuable abstraction.

"Each object is its own SQLite database, addressed by name and replicated to an S3-compatible bucket you own" -- this concept can take you a long way, both in its power and simplicity.

This is nicely done.

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.

This is awesome.

I think another audience for this is stock market traders and analysts who usually have Bloomberg and other channels up for watching market news.

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.

Yeah, this works fine unless you’re using something like DynamoDB or any system which requires you to have knowledge of the key.

For relational setups this is the way to go though. I prefer the combo approach though - autoincrementing numbers plus a UUID in another column.

Oh, boy, have I been waiting for this one! I've been building my own datomic-like datastore recently and this is going to be useful. Reading it now.

I enjoyed the MongoDB analyses. Make sure to check it out too as well as the one for Redis, RethinkDB, and others.

Would be great if there was an analysis done for rqlite/dqlite or turso/libsql at some point in the future.

This a great idea.

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.

The market timing of this ~1 day (same day?) after Supabase GA? Both are good platforms though.

Also:

- It'll be hosted in our data center in the USA. - It will have 4GB RAM, 20+GB SSD, super fast internet, and lots of bandwidth.

Like getting a Digital Ocean Droplet or an EC2. Except we're hosting it for you for free and you can deploy as many applications as you want to 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.

Sign up for the beta here: https://rx.run

TLDR: Issue with yarn also.

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.

I've been following this issue for some time. Having a large trash compactor/incinerator in space sounds so cool. Would love to help or join the team!

One word. Maps.

Short answer: Yes.

I've been nerd sniped! Emailed you.

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 definitely will!

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.

This would be a nice direction for the Node community. I wish for this. Especially since so many other platforms are supporting it out of the box.

Is alwaysStrict the same as strict? I think this skips a lot of the strict options that are usually the case for using TypeScript in the first place.

I generally agree with your statement, but have found ts-node incredibly valuable especially when developing servers or CLIs where I want to start/restart the process many times without a build step every time.

Strong agree. This has caused a major rift in the Node ecosystem (and for its packages).

All we can do is adapt and keep building. Using Node v20 (LTS) currently with the config linked in the parent post.

I agree that the migration experience has been subpar! I dropped ESM migration of my packages 2-3 times before finally picking it up again and wrapping it up in a simple guide. Hopefully with the config I shared you’ll find that you can use all those out-of-reach ESM packages now! Also, I provided examples for getting __dirname and __filename -like behavior.

You're right, but what guide is easier than "Just add the following files and run npm run dev. You'll be good to go!".

I tried `tsx` but it didn't work for some reason (can't remember why right now). Also, if you've been using `ts-node` and feel comfortable with it, this setup should work for you instead of switching your toolchain.

The "exports" and other sections are recommended things you'll need in your `package.json` file to support ESM. Sensible defaults. Also just points to an index.ts file (that you'll likely have in your project if you are developing a package).

Also, this project can be compiled with `tsc` or a bundler, of course.

In terms of speed, this should consistently start up an app or CLI in <3 seconds (depending on size of course).

What if a piece of data exists in multiple services? How does the tool know which service it should use to fetch the data, given the link is just a semantic representation - but that representation can exist in multiple places?

This has potential!

Also I encourage you to apply your talents to the mechanical engineering space (custom on-demand parts). Many companies need exactly this UI for their products, but don't have the engineering team to do it.