I've found the memory limits to block more of my projects than cpu time. They seem to send multiple requests to a single node/process and if you're making some sort of remix app it easily breaks with any kind of load.

The other thing i've noticed about burritos is that more places take card or apple pay now. When I moved to sf in 2015 many of them were cash only, same with bars. I always assumed some amount of cash was being shuffled under the table.

And when you take cards or things like tap to pay, you pay higher rates as a biz which gets factored into overall prices. But...good luck being cash only in a lot of places.

I still carry cash because services like massage and housecleaning and some restaurants are happy to give good price breaks for cash payment, but I also love Apple Pay as a consumer.

run your backend tests against this in memory and tests can be run in parallel instead of using a single real postgres instance

Our HoA uses google groups. Mild spam, but overall pretty good for threads. Too many people spam everyone asking for a plumber or whatever

What are you doing that requires checking in the compiled version. Esbuild takes like one second

The code is written in typescript. So we go from

    * cloning the action 
    * running the dist/index.js

to

    * Cloning the action
    * npm install
    * npm compile
    * npm run

You can run TypeScript natively in Node.js 24, actions based on that runtime don’t need a build step.

https://bsky.app/profile/danielroe.dev/post/3lxczp5apec2x

I think it just ignores types, so may not suit all use cases.

It has a (albeit experimental) flag for transforming enums, namespaces and other runtime-impacting aspects of TypeScript, if that’s what you were referring to?

https://nodejs.org/api/cli.html#--experimental-transform-typ...

That's fair, I'm referring to the number of mistakes that happen with local publishing. Publishing the wrong branch, not building from latest etc

So add a wrapper for that, a quick script that checks which branch and revision you are publishing from. The issue here is publishing from a CI you do not control that well and with automated events.

You can run the exact same script locally as you do in CI, with the only difference being the addition of a 2FA prompt.

That's a good point, I would lose package provenance that way. I guess that is fine since it didn't prevent anything here.

I can look into that.

Sorry if that wasn't clear. This was a token with global publish rights to my npm packages.

I was confused too. Was it your npm token stored in angulartics2 as a Github Actions secret, so it could publish new angulartics2 versions?

Yes, exactly.

there's existing libraries in this space that are quite good. not sure why you would use this instead.

storage for example:

https://github.com/unjs/unstorage vs byojs storage https://github.com/byojs/storage

most users are going to prefer autocomplete and types regardless of if they also use typescript.

esbuild can bundle typescript files directly, you don't need tsc to strip types

edit: nevermind i get what you're saying. check types with tsc and dev work with esbuild

I used vue 2 for work during the switch to vue 3. It was horrific to watch as the vue community had to relearn the worst parts of the class components and the massive shortcomings of both the template library type checking and the other parts that basically can't ever support typescript like class mixins. If you want to use vue with a .tsx file you might as well use react.

Today, 33% of vue downloads in the last 7 days are for vue 2.

There was a lot of things that were nice in the vue world like vite and vuex, but I'd never recommend vue to anyone, especially anyone that wants a good typescript experience.

here's an example library button using .tsx in vue https://github.com/vuetifyjs/vuetify/blob/master/packages/vu...

I feel like your experience is a bit jaded by the 2 -> 3 transition which is understandable because it wasn't the smoothest, but these days things are very stable, and you can even use the CompositionAPI in Vue 2.7 as it's been backported if you can't upgrade from 2 -> 3. Typescript support is also great because composables are just regular JS/TS files now rather than a Vue-specific thing, the only part that is a bit wonky is in templates sometimes, though for the majority of code out there even template type checking works just as you'd expect, I very rarely have issues even with huge components.

Pinia is Vuex, it was made by the same people specifically for Vue 3 due to otherwise having to introduce a lot of breaking changes and is a lot simpler than VueX was, as it leverages the composable pattern and gets rid of the need to do things like `mapGetters`/`mapActions`. And VueX 4 is still an option for those that prefer that approach.

> ... class mixins

Those were a pain point, but no longer relevant in Vue 3 as mixins have been deprecated. Again, composition takes its place and is in general much more powerful while being simpler. For a great example of what composables can achieve, I'd recommend taking a look at VueUse (https://vueuse.org/)

> Today, 33% of vue downloads in the last 7 days are for vue 2.

Another way to look at that is that the majority of the community is on Vue 3 :)

> If you want to use vue with a .tsx file you might as well use react.

`.tsx` is very much a personal preference thing and isn't really considered idiomatic despite Vue having support for it (unless you're a library author like Vuetify that you linked). I personally can't stand working with `jsx` and find Vue SFC's superior, and again, typechecking these days is much better than it ever was and will work just fine in 95% of situations. Especially with things like component generics being introduced, it's only gotten better and actively getting better.

I'd highly recommend you give Vue 3 a try with an open mind, because things have only gotten more powerful while getting simpler since the Vue 2 days.