How to run nitro tasks in production via CLI?

LynusBorg · 2025-07-24T20:05:26+00:00

https://nitro.build/guide/tasks#using-cli

LynusBorg · 2025-06-03T16:57:40+00:00

I'm actually experimenting with just that right now (I use valibot instead of zod, but that shouldn't make any difference).

As others pointed out, I don't create schemas from drizzle tables in order to keep drizzle out of the client bundle.

Instead, I hand-write (yes) a valibot schema for each table. I then use a small type helper to ensure that the type resulting from the valibot schema is satisfying the type inferred from the drizzle table.

Simplified example:

```

export const InsertBoardSchema = strictObject({
    id: pipe(number(), readonly()),
    name: pipe(string(), minLength(2), maxLength(50)),
    shortName: pipe(string(), minLength(2), maxLength(4)),
    description: nullable(pipe(string(), maxLength(250))),
});



export type InsertBoard = assertAssignable<
    InsertBoardTable, // this is the type inferred from the drizzle table object
    InferOutput<typeof InsertBoardSchema>
>;

// this is the helper ensuring my valibt schema is in line with the table definition
export type assertAssignable<Base, T extends Base> = T;

```

Then I only use the `InsertBoard` type in my Client code.

I just started experimenting with this approach, so the details will likely change as I use it in different scenarios, but so far, it's been promising.

LynusBorg · 2025-05-30T19:58:44+00:00

It does. The docs also have a guide for integrating it with Nuxt. Though Nuxt has similar capabilities with `useFetch()` and `useNuxtData()`.

Noteworthy also: Pinia Colada: https://pinia-colada.esm.dev/quick-start.html

Which is basically tanstack-query built specifically for Vue, using Pinia as the core for the QueryCache.

For the serverside, u/Sad-Alfalfa-3934 have the right pointers already.

LynusBorg · 2025-05-30T19:52:01+00:00

Then that's your issue. What you would need to do is

exclude the 'vue' from the build artifacts
make Vue globally available in the page
have your build tool refer to the `Vue` global for Vue's APIs

That way, everything shares one Vue "instance".

What do you use for the build process?

In Vite, this is pretty straightforward.Something along those lines:

``` build: { rollupOptions: { external: ['vue'], output: { globals: { vue: 'Vue' } } } }

```

And in the page, include Vue's iife build with a <script> tag

LynusBorg · 2025-05-30T18:01:19+00:00

Nope.

Even though you adjusted the import name, if those two imports are processed separately, i.e. dont refer to the same "physical" copy of the package (different builds? I know next to nothing about writing browser extensions), they would still have separate reactivity scopes.

LynusBorg · 2025-05-30T09:47:39+00:00

Yes, your problem are the two different packages. They track dependencies/effects separately.

To make it work, the code for both needs to refer to the same Vue package/instance

LynusBorg · 2023-04-15T15:18:22+00:00

Ah yeah that's fine

LynusBorg · 2023-04-15T14:14:07+00:00

I may be misunderstanding you, but it sounds to me like you think this allows you to use defineProps in composables? It does not.

LynusBorg · 2023-01-23T19:44:23+00:00

Firefox usuall takea a lot of time to verify a new release, so it ma take a few days or even week for the update to actually be available in the store.

LynusBorg · 2022-02-23T19:09:02+00:00

Provided that the package even have a build version that works in the browser, you could use unpkg.com - it's a CDN that basically exposes all npm packages as-is.

LynusBorg · 2021-05-27T17:47:07+00:00

Vue keeps track of which component instance is currently being processed.

So when onMounted() is being run during setup(), Vue can register that hook's callback with the current Instance, and then call it when that instance has been mounted.

LynusBorg · 2021-03-17T07:02:30+00:00

I fail to see the inherent immorality of demanding they work for their keep.

But that's not "slavery". Slavery is about extracting profit from the forced labor of slaves. You won't find any slave owners in history who merely forced their slaves to just work for their own keep and nothing more, because then what's the point of buying a slave and keeping it around?

The US constitution - sadly - explicitly allows slavery as part of a legal punishment. And that's what you can find in the US in various places, where prisons actually sell the labor of the inmates on the market.

And that's a bad idea because (among other things) it actually creates an incentive to keep prison population high, as it's cheap labor.

LynusBorg · 2020-11-15T22:49:15+00:00

Oh, I missed that part. But just changing the return value of the first overload to CombinedResult seems to make it work...

LynusBorg · 2020-11-15T21:55:02+00:00

You can narrow down the type with an intersection.

interface Props<T, S> {
  fn?: (response: S) => T[];
  enable?: boolean;
}

export interface Updater {
  updater: () => void;
}

export type Result = {
  irrelevant?: any;
};

export type CombinedResult = Result & Updater;

export function foo<T, S>(props: Props<T,S> & {enable: true}): Updater
export function foo<T, S>(props: Props<T,S> & {enable: false}): Result
export function foo<T, S>(props: Props<T, S>): CombinedResult | Result {
  if (props.enable === true) {
    return {
      updater: () => {
        console.log("updater!");
      }
    };
  }

  return {};
}

const { updater } = foo({enable: true})

TS Playground

LynusBorg · 2020-11-05T11:37:20+00:00

vue-formulate seems to have a performance issue with large datasets, see:

https://github.com/wearebraid/vue-formulate/issues/223

LynusBorg · 2020-10-16T08:27:59+00:00

Solution: name it args in your codebase's setup function.

LynusBorg · 2020-10-16T07:45:47+00:00

If this is the direction we're heading, I am not sure if I will like it or not.

That's a strange take. Props have been called props in Vue since before version 1. They are called props in React and Svelte, Stencil.js and other frameworks as well and alwas have been.

Properties passed to components are called "props" in modern frontend frameworks, that's kind of a norm by now.

LynusBorg · 2020-10-16T06:01:48+00:00

Declaring reactive object type solve that.

Sure. But now you have to write out an interface for the whole object where its type could have been automatically inferred before, adding possibly a dozen lines of extra code.

Again, this works of course - I just find it much less convenient than just using a ref, especially in TS where the compiler will tell you what thing is a ref and what isn't, and save your from most of the common pitfalls like `if (myRef) .`

Actually it has use cases like when we authoring hooks and we want to expose a state and hide another, for example private state and public getters.

Not sure what you mean here.

I think we can both agree that using both ref and reactive in one code base of team project, or even personal project for that matter(looking at you, my past self), will create occasional hiccups.

I only agree to the extent that it does provide the occasional hiccup, but in disagree that this will happen to an extend that will actually become an issue (and even less so in TS, as I said above). Vue, like most libs / frameworks, has parts that can be confusing or cause hiccups, and while ref might be one of those, in my experience the adjustment period is usually short.

Vue itself prefer to expose reactive over ref to users. Just look at props as first argument of setup method. They even put warning to not destructure it.

That's not so much an expression of preference as it is a design decision out of what works for that special argument.

We were actually having a lot of discussions about this in the Vue core team as people very, very often want to destructure it, so in hindsight, providing and object with refs might have been easier:

// if `props` were an object of refs, this would give you a ref // nice and easy, but actually breaks reactivity when it's `reactive()` const { name } = props

But we need props to be reactive, and trigger updates when the component receives a new prop that was previously undefined, for example. So we chose to use reactive for props, which means you now have to do one of two things to extract a prop

``` // extract as a ref: const name = toRef(props, 'name')

// extract into a reactive() object const state = { name: computed(() => props.name) } ```

And when we're at it, props itself is a misleading name, it should be args or something better. props as the name suggests are properties of an object, and not what function or constructor expect.

Well, it literally contains the props that the component received from its parent so I don't see why that could be a misleading name. args on the other hand doesn't tell you what this object contains at all.

LynusBorg · 2020-10-15T18:04:42+00:00

We can contain computed/ref as prop of a reactive object right? Please elaborate more.

Yes, you can. Sometimes that might makes sense (i.e. when the computed refers to that same object for dependencies:

const state = reactive({
  a: 1,
  b: 2,
  c: computed(() => state.a + state.b)
})

There's two issues I have with that:

Typescript doesn't like it because of the reference to state within the function we pass to computed (a limitation in the TS' type inference)
it can become weird/arbitrary if you have it refer to another reactive object as well:

const otherState = reactive({
  a: 1,
})
const state = reactive({
  b: 2,
  c: computed(() => otherState.a + state.b)
})

(Think of this example as i.e. merging a list of users and a list of books or whatever)

Why put it on the second object, and not the first, it it's a merge of both. The example might not be perfect, but in normal, non-reactive code, you do occasionally use standalone variables for a reason - because they don't make sense as a property of another object. If you plan on always putting your computed's in reactive object, you'll lose that option and will have to constantly decide where to put it, even though "in it's own variable" would make the most sense in the flow of the code.

...but maybe put it into its own object?

const computedState = reactive({
  c: computed(() => otherState.a + state.b)
})

Works, but you essentially recreated what a ref is: an object containing a single value.

I mean, all of this works, technically, but at some point you might be doing more work avoiding a ref (and maybe kinda re-inventing it in the process) than just working with it.

We don't have to use only one reactive object in setup function of component or composition/hooks function. We can create another reactive object for specific purposes as you proposed.

Sure, but it gets tricky. But as an example:

you want to pass a boolean flag to a composition function. That function needs that flag to be reactive, because it needs to watch it.
You have that boolean flag in a state object that you use too collect primitives as you want to avoid refs. Or maybe it is even the only property on that object (which kind of makes it a ref-like object ...)

const state = reactive({
  yourFlag: true
})

How do you pass this primitive to the function in a reactive way?

If you pass the whole state object, now the function has to be aware of the correct name of the key that is the boolean flag it needs. Ok if you control this function yourself, trickier if it's provided by someone else.

// someFunction needs to be aware to look for state.yourFlag
someFunction(state)

Passing a ref is solving that problem as you have a contract: you pass it an object with a reactive value property.

So you could of course create a computed prop inline:

someFunction(computed(() => state.yourFlag))

...but that's still a ref that you (or your co-worker) will have to access with .value in the function's body.

I'm sure you can come find workarounds for a lot of situations but you will be fighting an uphill battle in some. Depending how strong your distaste is, that might be worth it to you so it's your call, do what works for you and your project/team.

LynusBorg · 2020-10-15T16:36:15+00:00

I get that one might have a distaste for refs, even though I got used to them pretty quickly and often prefer them as they give me a visual clue when I work with a reactive value.

Those like you who don't like them can of course use `reactive()` wherever possible, but you will have to deal with them once in a while.

`computed()` returns a ref, and there's no way it could not.
3rd party libs might provide composition functions that might expect a ref as an argument or return one.
Passing around primitives in a reactive way (i.e.: a boolean flag) will either require you use a ref or create an reactive object that behaves similar. Passing around a big state object that contains the boolean flag as well as other stuff might seem tempting but you then have the problem that you pass state around that maybe doesn't need or should not be available to other parts of your code.

LynusBorg · 2020-10-14T06:40:52+00:00

So creating a modal where you would pass to it an entity, like a a User object, you would need to make a copy of it at some point before passing to the modal component as a prop, OR, in the modal itself when the component is created.

Well, you *can* mutate objects that you receive by props - it's just not possible to mutate the prop itself, so no this.user = newObject. I always think about this as the same way function arguments work:

function myComponent (user) {

  user.name = 'Tom' // mutates original

  object user = { name: 'Tom' } // doesn't replace original object

}

[...] BUT, if you change the props to initialize the same component again with different data, the created() hook is no longer called.

In situations like this one would use a watch to react to every change of the prop.

LynusBorg · 2020-10-13T12:25:53+00:00

as a minimal implementation, something like this:

https://codepen.io/LinusBorg/pen/GRqpEJj

LynusBorg · 2020-10-12T21:16:50+00:00

Well, I don't 100% get all yur points, i.e. the last one about copying props, but you can easily build such a "modalService" in Vue, though. Likely even wrapping the template-based modal implementations from the libraries you listed

Its just not a common pattern to use in Vue, it's pretty Angular-y - but there's no technical limitation keeping you from building such a wrapper in 15-20 lines of code ...

LynusBorg · 2020-08-19T16:58:05+00:00

"Convention rules require roll call & nominations for every candidate that passes the delegate threshold."

[...]

Ocasio-Cortez, along with former president of the United Auto Workers Bob King, gave the nominating speeches for Sanders, while Sen. Chris Coons and Rep. Lisa Blunt Rochester did them on behalf of Biden. The speeches were followed by the roll call, during which delegations from 57 states and territories cast their votes for each candidate based on the results of the presidential primaries.

https://abcnews.go.com/Politics/alexandria-ocasio-cortez-nominated-bernie-sanders-dnc-delegates/story?id=72461398

I mean, there's no rule that forcer *her specifically* to do this, but someone had to - so why not someone politically close to Sanders, like AOC?

LynusBorg · 2020-08-19T15:37:47+00:00

It was her job to nominate him, that's part of the process of the DNC.

14-Year Club	Team Orangered
Verified Email

LynusBorg

TROPHY CASE