Forem: Alois Sečkár

Dafuq did I just installed?

Alois Sečkár — Wed, 08 Apr 2026 08:31:41 +0000

During the recent Axios Supply Chain Attack I have accidentally observed couple of devs checking whether they should be worried about their projects or not. I have noticed one interesting thing - the level of understanding of what's really going on, what is the nature of this kind of exploit and how to reliably protect yourself from future ones, is lower than it should be. Therefore, I decided to put together a few paragraphs that should help.

I am far from being a Node.js security guru, yet I believe I have learned a thing or two on my dev journey so far. If you insist on meeting the real expert, allow me to introduce you Liran Tal and namely his Awesome npm Security Best Practices repo with a huge list of dos and don'ts when dealing with NPM packages. For less scholarly version, you may proceed to my article.

What happened?

This type of cyberattack occurs when hackers gain credentials that allow them posting malicious versions of existing and legit packages. In this case, sophisticated social engineering was used to steal them directly from one of the devs. More common ways are accidental leaking (vibecoders, do you know what your AI coding assistant is committing into public Git repository?) or exfiltrating data through previous virus infections.

It usually doesn't take long before the malware is discovered by automated checkers, the maintainers are notified, and the infected packages are pulled off NPM. But during this time frame damage can be done.

The malicious code typically lurks in what is called a postinstall script. This is a code that is automatically executed once the package gets installed. While there are many legit use-cases for this, it might also become an open door to your system. And hackers know it (while many JS devs don't).

Why is it happening?

Despite it is quite easy to exploit npm's default behavior, it is also not that hard to build a good defense to prevent most of the common attack vectors.

So, let me first explain why it can happen and then I'll aim you with solid ways of fending this attack off.

NPM package resolution

One of the first commands you'd use when working with JavaScript is npm install. You probably know that it downloads dependencies listed in your package.json file into local node_modules directory. But the whole process is more complex.

When executed for the first time, it reads through package.json and resolves listed packages along with their versions. The version may be specified as an exact one, but you can also see caret (^) or tilde (~) ones. Those allow npm to use latest available version within the given range.

Exact vs loose versions

I'll assume you are familiar with semantic versioning or you will take a break now and find out. The important take is: It is effectively impossible to predict the exact outcome of a fresh npm install.

I mean, yes, you can pin down all your (direct) dependences, but:

You will have harder time maintaining security updates in the future
The first external library you pull in will probably contain some loose dependencies anyway and you won't be able to control all (unless you use overrides for each and single one - and get #1 squared)

I initially thought trying to pin down everything should be my goal, now I am far less convinced. Especially if you develop a library-like solution, you don't really want to make your future users dependent on you. Because if you strictly pin your dependencies, each time a vulnerability is uncovered (like couple of times per day), you would need to update your package.json and release new patch version of your library. With loosen dependencies, tools like npm audit --fix will be able to bump the required version directly in consumer's lockfile. Not only is this more convenient but it is also faster, because I reckon you are not always online to be of service.

Automated vulnerability

But this comes with a price. If a malicious version of a package exists at the time installation process runs and it is within the allowed range, it will be grabbed, downloaded and if it contains extra scripts, they will be executed.

It is hard if not impossible to reason with vanilla npm install. The flow is deterministic, but its scope is almost always too large as real projects contain many dependencies that are dependent on something else themselves. Would you take the time and control everything? Admit it - you just trust the system.

And the recent events (or the Shai-Hulud attack last year) showed us the blind trust may be dangerous.

What to do?

One would say JavaScript installation process is inherently unsafe and you better should just run away. But before you do, here are the three things you can easily do to mitigate most of the risks.

Disallow postinstall scripts by default

In cybersecurity awareness trainings you are taught not to click any suspicious links. Yet npm happily runs any suspicous script it gets. Unless you tell it not to do so.

The command is easy. Just use npm install --ignore-scripts instead of plain install. All of a sudden, no 3rd party scripts will be executed.

However, it is a double-edged sword, because there might be legit packages that rely on automated postinstall script and you'll end up in broken state unless you take further manual actions (like npm rebuild <package>).

Or, you can solve this in much more elegant way by switching to pnpm (which you should absolutely do for a number of other reasons as well). When pnpm runs install command, it never allows any scripts by default and only white-list those you allow via pnpm approve-builds manually or specify through onlyBuiltDependencies setting.

Either way, you should absolutely limit what is being executed and do not put yourself to the mercy of 3rd party package creators.

Commit your lockfiles

I remember having a conversation with one of my former colleague: "Oh, you don't commit package-lock.json into Git repository. It is big, it keeps changing and people keep creating conflicts by (accidentally) changing this file." I was taught differently back then and I insisted: My project will have the lockfile committed." After a few years, I am now pretty sure I was right.

The so called "lockfile" is created when the package manager runs install for the first time and gets updated when:

some (direct) dependency was changed in package.json since last installation (the most common and expected way)
you run npm install <package> or npm uninstall <package> (effectively the same as #1)
you run npm update (this re-resolves loosen caret/tilde deps) or npm audit --fix (this auto-patches known vulnerable packages, if prescribed version ranges allow it)
the package manager version is different (the unwanted source of confusion and conflicts around the dev teams)

Otherwise, you will end up with guaranteed "bill of materials", that doesn't change between builds. Not only this helps to reduce infamous "it works on my machine" bugs, but it also fully prevents sudden changes in the supply chain.

If you don't include lockfile in your repository, everytime the repo is pulled (manually or inside an automated pipeline), new fresh npm install runs and up-to-date dependencies are re-resolved. The final build will be almost always different from previous one.

To be even safer (especially in pipelines), you can switch from using npm install to npm ci (aka "continuous integration") - a command that works mostly the same but completely respects existing lockfile and doesn't ever try to change.

Install with cooldown

The above is good, but if you're unlucky enough, you will create/update lockfile exactly during the ongoing supply chain crisis.

Fortunately, such attacks are usually short-lived. In the latest Axios case, it only took like 6 minutes before the compromised package version was discovered and totally 3 and half hours to take it off. It is very unlikely some malicious package can survive longer than let's say a week. If we can establish a rule that every package version we install must be at least a week old, we would easily prevent 99.9% of such incidents.

Good news everyone! It is possible with npm. However, there are buts.

If you already updated to newest v11, you were gifted with minimum-release-age flag. This allows you to specify the minimal number of days that had to pass between package release date and today. Newer versions will be rejected (silently if there is older fallback allowed by the version constraints and with failure if some exact version is requested).

Versions v10 and earlier had to rely on slightly less ideal before where YYYY-MM-DD date string is passed. This might get tricky to allow rolling dates and you had to do some scripting magic to achieve it.

Again, this will protect you from newly published malware, but it will also cut you off from desired updates (like urgent security patches).

And again, I cannot but advise you to switch to pnpm, because it naturally combines minimumReleaseAge with minimumReleaseAgeExclude to solve exactly this problem.

Summary

I am not promising following the advice above will always keep you safe. The topic of Node.js security is complex, and hackers are creative. But many exploits occur only because someone was unaware/lazy/hasty and left a plain npm install without taking at least minimum precaution.

Yes. If this is new for you, you may find it confusing and overwhelming. The working pipeline suddenly broke. You eagerly tried to use pnpm but the container image you use for builds is not knowing it (RUN npm install -g pnpm to the rescue). You imposed cooldowns and installation log exploded with errors. You banished post-install scripts and now your app won't start. But all the issues can be solved, and you will be rewarded with better sleep knowing you don't have to freak out every time new cyberattack is announced.

If you have questions and remarks, feel free to share your thoughts in the comments section below. Maybe you know something that I don't and I will be more than happy to find out 👀

New in Vue - March 2026

Alois Sečkár — Sat, 28 Mar 2026 11:49:43 +0000

I promissed new summary once VueJS Amsterdam is over. It took me two weeks longer, but there we are. Hear, hear! I bring the latest Vue news.

Unfortunately, I must start with a sad announcement - the Weekly Vue News, the invaluable source of inspiration for Vue devs are no more. Their long-time curator Michael Hoffmann called it quits. Let his hard work be remembered.

But life goes on. And the life in the Vue ecosystem is everything but steady. So lets recap the new releases:

The most significant one would be the Vite 8.0. Why? Because Vite is nowadays fundament for modern JS development. And v8 brings important updates like using brand new and super-fast Rolldown bundler. There was a beta testing phase running since December, and now the stable version was made available.

On top of that, there is Vite+ - a unified modern toolchain built with the latest available features as "This is the way" of developing webapps in 2026. The current state of the project is Alpha with stable release expected soon.

Vitest, the testing framework, couldn't stay behind and released v4.1. Unlike the significant v4 update, this is rather a service update to natively support Vite v8. But there are also some new features to give a try. If you don't use Vitest in your project, you should think about it.

Nuxt, the #1 framework to go with Vue projects, continues its steady evolution, with v4.4 being the latest release. With each minor version something new appears, although the changes are not really revolutionary. The same applies for Nuxt UI, the official UI library - the v4.5 and v4.6 were released since my last newsletter. For smaller projects, you really don't need anything else to handle the appearance and basic UX.

Nuxt already foresees its version 5. You can even opt in into future forward compatibility through a setting. One of the prerequisites is the finalization of Nitro v3 JS server engine. This milestone is now one step closer as its beta phase has started.

Among new tools, I want to point out first stable release of Pinia Colada, the advanced Vue solution for data fetching and state management. You probably have heard of Pinia, this brings the concept further created by the same author.

I must not forget about evlog, the new logging tool by Hugo Richard, one of the Nuxt team members. I haven't touched it yet, but I really want to do it soon. I really like the idea of having my logs better organized. Logging is generally hard - it doesn't matter until it's too late. Right?

If you are trying to keep up with the times and use AI to boost your developer performance (which you absolutely should), this might be useful for you - Daniel Kelly from VueSchool wrote an article about Vue Agent skills that should gradually improve the quality of GenAI tools output.

Last but not least, we have a new TypeScript version. Microsoft released its stable version 5 days ago. However, this version is considered rather a less important bridge on the way to v7, which is expected to be the real change after its core being rewritten to Go language for better performance. So you don't necessarily need to drop everything and start migrating your codebases to v6.

That's it for today. When I approach you the next time, I hope I would be able to share details about the PragVue 2026 conference we are about to organize for the third time already. Until then.

Edit: fixed title from March 2025 to 2026. Thanks Arvind PJ for spotting out.

Upcoming events

Vueconf.US 2026 - 19-21 May 2026, Atlanta [USA]
MadVue 2026 - 22 May 2026, Madrid [ESP]

Past issues:

Follow me for more updates on Vue, Nuxt, Vite - and maybe even more!

Speed of Vibes: We can turn bathroom ideas into features within minutes now

Alois Sečkár — Sat, 14 Feb 2026 21:15:44 +0000

A month ago, I wrote I am a rational pessimist about AI. Yesterday's dispute with my co-worker about unnecessary complexity of AI-infused Korn shell script delivered by our other colleague reminded me there are also radical pessimists among us. However, every day when I dare to go further into the uncertain wilderness of imperfect prompts followed by indeterministic and not-always-right responses, I see progress, new opportunities and new ways of doing better.

Today, I have another success story to share.

It started one evening after a workday recently. I came back from my daily dev job and went running to compensate for hours sitting in front of a screen. After the jogging session I was in a shower and suddenly got a cool idea for my side project.

I thought it would be nice to provide to my future users a convenient way of reporting bugs. But also to make it convenient for me. I would be happiest to have reports appearing as GitHub issues. But teaching BFUs to login to GitHub and creating new issues in a consistent way? Good luck with that. So what if I just provide a simple form on my website and wire it to a backend service that will collect the input and create the issue automatically?

Sounded like a plan. But imagine all the work you need to do. Putting together the form, writing the backend service, figuring out how the GitHub API works exactly to be able to call it... Let's just put the idea into the inner memory deep in the back of my brain and we will surely look at it. One day. Not today... My inner demon of procrastination nearly won again.

But times have changed lately. Now I am armed and dangerous with tireless AI companions. Despite all those legit complaints about coding agents not doing their job as good as you would hope and not nearly as great as AI-driven companies keep promising you, in early 2026 your favorite excuses "I don't know how to start" or "This task is too big to start it today" are no longer valid. You can always just kick off with a simple natural language prompt and see how it goes. Even the last season's truth that the prompt needs to be well designed (and thus you "cannot" start as "I don't know how to write a correct prompt") is fading out.

Before going further, I'd like to make a statement. This doesn't mean I am encouraging you to just fire ambiguous prompt and YOLO-deploy the first iteration right into the production. The AI Manifesto is still valid and you should always verify the results, reason about code and understand everything before moving on. It is easier for me as a senior dev, but if you are a beginner, the more important it is before you get lost and become a hostage of a machine mind. On the other hand, you shouldn't hold yourself back too much. AI is there for you. Use it. Benefit from it. 💪🦾

Before I finished bathing, ate dinner and socialized with my family, it was already getting quite late. But I was feeling lucky and wanted to try.

Here is the prompt for my (paid) Copilot I quickly put together:

I want a new feature in this Nuxt 4 project. I need a new client page 
"/report" with a Nuxt UI form entitled "Report problem" that will include 
text field for "gameLink", radio switching between "report false positive" 
and "report false negative", text field for "issue" and text area 
"description" for describing the issue to be reported. All fields will be 
mandatory. The filled form will be send to backend API route where it is 
validated and then a GitHub issue in <<REPO>> repository is created from 
given contents. Issue will be named by "issue" field and contain both 
"gameLink" and "description". Selected radio value will result into 
corresponding label (that will be prepared in the repositry). The report 
form is annonymous, there will be dedicated service account with access 
token to create the issues configurable via Nuxt runtime config (server-
side, so NOT public).

Just this. No context engineering, no MCP servers, no skills or whatever. Just my codebase, internet connection and the rough task description in natural language with a few instructions and restrictions. Typos and grammar mistakes included.

Maybe one thing. If you are AI-geek, you may have noticed new model Claude Opus 4.6 was released recently. I did notice and I also decided this was a perfect opportunity to test it in action. And I wasn't disappointed.

I spent two, maybe three minutes writing the prompt (while already have it more or less ready in my mind). Copilot with Claude took about 4 minutes to deliver the result. The surprising part was - the code was nearly perfect!

I was trying, but I was unable to find any significant flaws. It created decent frontend form, it added Zod schema validation, it created backend endpoint, handled and validated the incoming data, put together the GitHub API call and wired the response back into the client. It even noticed there was no <NuxtPage /> yet and made adjustments accordingly to support new /report page along the existing (implicit) /index. Yea, I might do some refactoring and polishing later, because looking back, the code might be more compact and less verbose. But overall it was not glued together somehow until it accidentally worked. It was a decent job. I don't think I would do much better for the first iteration.

My victory wasn't so flawless, because then I spent at least 30 more minutes configuring my new GitHub service account and getting the proper access token (AI-backed again). But overall it was less than an hour from the first keystroke to test issue successfully created in my repository. Wow! 👀

There were a few success points that helped:

I knew what and how I want to do and I know Nuxt good enough to request general architecture with at least basic level of security (i.e. token must be kept on server-side and not exposed as public config).
Copilot wasn't building from scratch but inside already established repository with configured Nuxt UI and existing server routes to copy from.
People from Nuxt ecosystem are working hard to create AI-friendly solutions so it is much easier for agents to get relevant up-to-date information.

I was hoping for good outcome, but this really amazed me. It reminded me that it already me who is being the bottleneck. My hesitation, my reluctance and my incompetence to delegate tasks that should be delegated without losing control. Despite I am still not scared about my very existence as some fellow devs seem to be, I was re-assured I should know much better. And I will keep trying to do so.

What about you? What are your recent experiences with AI? Feel free to share your stories, questions, objections and concerns in the comments below 👇

New in Vue - February 2025

Alois Sečkár — Sat, 07 Feb 2026 08:14:42 +0000

As you probably didn't even notice, I skipped January issue of my wannabe monthly newsletter. I was in a hurry towards some deadlines, and I wrote 3 other articles in 2026 already. So I decided not to post some half-baked something last Saturday and to postpone the release. Today I am travelling by train from Prague to Ostrava, which is always a good opportunity for creative work. Here it comes.

Nuxt began 2026 with a new minor release 4.3. Among numerous updates and improvements, it is now possible to opt-in into forthcoming v5 features via a setting. Nuxt v5 shouldn't be a revolutionary update with large API and behavior changes, but it will bring completely re-worked Nitro v3 server engine promising faster and more effective execution with a number of new cool features.

Edit: Patch version 4.3.1 landed just a few hours after I finished my overview.

Owners of larger projects also got a pleasant announcement about the official support for Nuxt v3 being extended by 6 months - from end of January to 31 July 2026. That gives everyone more time for migration efforts. Some are complaining that the support period should be even longer as production teams need more stability but remember Nuxt is an open source-project. Despite handful of the team members are now being paid by Vercel, the solution capacity is still limited. I would rather see new features being developed than legacy code being maintained indefinitely for (often non-paying) users.

There are two new official Nuxt modules around the corner. Nuxt Accessibility will focus on dealing with accessibility issues by providing ways of testing and giving hints during development. Nuxt Hints will go even beyond that and should provide insights about your applications' performance, accessibility, and security. Both modules are now in alpha stage towards their v1 release which is expected soon.

Formerly paid premium feature Nuxt Studio was made free and fully open-sourced. The transition process started after Vercel acquired NuxtLabs last summer and was finished at the dawn of 2026. Nuxt Studio used to be a way of making money for Nuxt development. As this is not necessary anymore, you have this advanced CMS solution at your disposal now.

Adam Berecz announced his Vueform 2.0. I learned about Vueform 11 months ago from his conference talk and I immideately liked it. Now it seems there will be a paradigm shift from more opinionated form-handling solution to a headless core that will allow smooth extension by almost any UI library. Looking forward to the result. Forms are a big (and somewhat painful) topic, and I am afraid I haven't picked my dream setup yet. Another player out there might be Formisch which is being developed from last summer by Fabian Hiller, the author of Valibot validation library. But since Nuxt UI also opensourced their previously paid components, maybe their Form is all a Nuxter would need? I am planning to experiment on this theory a bit...

Let's not forget about broader Vite ecosystem. As you may have heard, one of the fundamental parts of the ongoing improvement efforts is Rolldown. The bundler written in Rust is made to be crazy fast and effective in building modern webapps. Vite version 8, which is already in beta stage since December, will be powered by Rolldown exclusively. And soon there will be standalone Rolldown release, we already have release candidates. And there is much more going on as you can see in the fresh monthly summary by Alex Lichter.

Last thing that caught my attention lately is npmx - an alternative frontend to NPM package registry. It is an open-source project, currently under active development, that promises improved experience when browsing NPM packages. Not a competing repository and ecosystem, just an alternative frontend with additional features. I was satisfied with classic https://www.npmjs.com/, but this seems as one of those updates you don't know you need until you get it. I will keep my eye on it.

I plan to release the March issue after VueJS Amsterdam conference. This year I am not travelling there in person, but I will keep my eye on the updates and I am sure there will be a lot of news to talk about. Take care until then!

Upcoming events

VueJS Amsterdam 2026 - 12-13 March 2026, Amsterdam [NED]
Vueconf.US 2026 - 19-21 May 2026, Atlanta [USA]
MadVue 2026 - 22 May 2026, Madrid [ESP]

Past issues:

Follow me for more updates on Vue, Nuxt, Vite - and maybe even more!

I cheated to maintain GitHub streak and I don't regret it

Alois Sečkár — Sat, 24 Jan 2026 14:13:23 +0000

Since September 2022, I am actively trying to have a GitHub streak - every day at least one new contribution. And yes, I totally agree with you, it is meaningless. But it has a meaning for me. I want to do it, and I want to keep it. Even if some days the contribution has little to no value - like just adding a new article I have recently read into one of my news lists.

I used this widget to display the number of days on my GitHub profile. It was great until it stopped working some time ago. Some API changes probably. Maybe it'll come back eventually. But I didn't want to wait. I found an alternative that works here and now.

Except it doesn't work the same way as the previous one and as the GitHub commit graph itself. It only counts "real" commits, it doesn't recognize code reviews.

And this pointed out a flaw in my beloved streak. One day, June 1st, 2024, I somehow forgot to actually commit something. I "only" did two reviews for my Dependabot updates. I didn't notice, because when I opened GitHub page, the day was green. But my streak suddenly dropped by more than half 🥹

I could have just let it go and accept the bitterness. But I didn't want to. The other day I did four commits! What if I just virtually travel back in time and alter one of them to fill in the gap? 💡

And so I did. And the timeline was fixed. And I can enjoy my 1236 and counting streak. End of the story.

But this wasn't meant to be just a confession. And I don't ask for redemption. The title says I don't regret it. Here I wanted to explain why not.

Because due to this "cheating", I learned to know Git better than before.

Git is one of those things you can adopt in a few minutes and then spend a lifetime trying to really understand it. Btw it took just 10 days to forge this backbone on modern development. Stories like that keep reminding me how mediocre I actually am.

To be able to change a year and half worth of my project Git history, I needed to understand how to work with git rebase command. How to find the correct commit and how to alter it via the interactive mode. The biggest Aha! moment was realizing that once you do this, you effectively erase the current history starting from the altered commit and you'll get a new one. The changes and messages remain the same (except what was changed), but all commits will become new with new hashes. I used git rebase before, but only to fix very recent issues. So I successfully overlooked this fact. Now I am smarter.

Another 🤯 thing I have learned is that when using GitHub, there are two commit dates - the original Author Date (marking the point of time when the commit was created) and Commit Date (changing when the commit gets edited - or rebased). I learned it the hard way after I force-pushed my changes to GitHub and suddenly 150 commits were "made" on 17th January 2026 😰

That unfortunate event directly leads into my third discovery of existence of git filter-branch command and (more modern) git filter-repo tool. Those can be called into action to do bulk updates over commits. And help undone lapses like mine. So no worries, after another trial-and-error session with Copilot, I managed to repair my flawed Git history, and you could never tell again.

And that concludes my story. If you already knew all the above, good for you. It took me like 8 years of working with Git to dig that deep. I guess one can go even deeper, but I will take a break for a while. If you have stories to share or questions to ask, feel free to express them in the comments below. And stay tuned for another Alois discovers trivial things article.

Disclaimer: You should be careful when tampering with your Git timeline and force-pushing something in the repository. If you have changes in other branches or even uncommitted in your local checkouts, you may get into trouble. If the team is bigger than just you, the troubles may be even bigger. I could afford to ignore those concerns as it was my private repo with no WIP. But this is not always the case.

AI the way out of doubt

Alois Sečkár — Sat, 17 Jan 2026 08:17:54 +0000

When it comes to AI, I believe to be a rational pessimist. I am using AI-powered tools here and there, but I don't see it as a second coming of Jesus that would take our dev jobs and replace us. It is a useful tool, but only a tool. This is probably why I am always a bit behind the newest features and trends that keep emerging every week.

On the other hand, I am not reluctant to AI either. I don't think it is crippling my mind not to write everything by hand and rather focus on the bigger picture than wiring all the boilerplate together. But finding the right tasks to be asked about or even delegated to AI-agent seems to be the biggest bottleneck in my workflows. I am being constrained by too much thinking.

While the other extreme - not thinking and all and just vibe code the entire app and let it to production without any sanity and security checks - might be even worse, not shipping anything, because you cannot decide how to put it together, is not the ideal outcome either. Whenever I manage to break from the circle, the positive results surprise me. I decided to write this article to share my latest small win achieved through AI. Maybe it inspires you too.

The scene

I have a custom page where I collect and keep all my running since 2013 - where I run, how many meters and what time. I am just a casual runner, but it's becoming decent set - nearly 2000 entries and closing to 12K kilometers. And it all can be tracked down to March 11th 2013, when I started with first 1825 meters in 9 minutes and 15 seconds.

The website offers both displaying and filtering the records and the simple admin form, so I can add new record just after I stop running from my phone. It was evolving over the time from custom PHP glued to HTML page to being part of a Nuxt application with using my own nuxt-neon module for database connection.

It had one big flaw - for simplicity, I placed logic to frontend and then never troubled with moving the database operations to server-side. Because noone really cared about my running data, there was no urge to change it. I was always like "yeah, I should do it", but then always like "but not today".

The process

Last Wednesday was another such day.

Productive me: _I should do it now. I need some task for daily GitHub streak anyway."

Lazy me: But I am tired from coding all day at work. And surely some issues will arise and I will have to sort them out till midnight. Nah, let's play videogames instead.

But then for some reason I got that little lightbulb above my head like in cartoons. What if I just try asking Copilot to refactor my code and see what happens?

I nearly fell in the How to write the correct prompt? trap, but this time I didn't get distracted. I decided to apply KISS principle and see.

Therefore, my first prompt was pretty straightforward:

Refactor "getTracks" and "getRuns" methods by moving them to Nuxt server side 
and expose as API routes under /server/routes/tracks.get.ts 
and /server/routes/runs.post.ts. Preserve the "filter" as POST input.

Few months ago, my newsfeed was full of articles about prompt engineering or even context engineering as an emerging must-have skill. But fast-forward to present. Your codebase is the context and even a mere Copilot (with Pro subscription) can understand simple prompts good enough to deliver expected results. I am using Claude Sonet 4.5 model recently, but I didn't really try any comparison with others.

It was thinking and working for a while and then I got my refactor. Being aware of The AI Manifesto, I didn't just accept the something it spit out. I went through all changes carefully.

This is a big advantage for us, seasoned devs - we can verify the results by understanding the code. Even if I am using AI to discover how to do XY, I can follow up to some level and get a basic idea about what is going on. And I can challenge parts I truly don't understand, asking What does this do? or Why you put it there?.

This time the code review was easier because I know how to write a Nitro route. I just took liberty not to since now I have a pocket junior dev who can do it for me. I wouldn't be bothering you with implementation details, I have a series of Nuxt tutorials if you're interested.

Anyway, the outcome exceeded the expectations. The delivered code was fine. The only issue that Copilot cannot foresee (unless I would ship an MCP server along with my nuxt-neon module) was that I recently split server- and client-side composable, so it must import useNeonServer instead of useNeonClient.

I fixed that manually. Towards Copilot, I had one additional remark:

Do we need "useAsyncData"? Shouldn't we be fine with "useFetch"?

This was merely a cosmetic thing, the simpler way of achieving the same result - getting data from backend into frontend. And honestly, it was my fault, because I was using useAsyncData in my code and gullible Copilot just copied it. But he also delivered a fix in no time.

Reading data was secured at backend. Now I needed to do the same for adding new runs. My third prompt was:

Going further. Lets also move "submitRun" method from client side Form.vue 
to new server side /server/routes/runs-add.post.ts and redirect client 
Vueform component to it.

This was fast including AI picked up change to useNeonServer and mimicked it correctly. But a technical issue arose - because the data from input form are being posted as multipart/form-data, standard Nitro readBody method cannot be used for parsing the request. The correct method handling this case is readFormData. Copilot helped me debug based on a simple console log and fixed the error itself.

The last piece was to migrate function for deleting erroneous entries:

Last refactor. Move "deleteRun" from Table.vue to backend to 
/server/run-delete.delete.ts

This would have been a walk in the park, if I didn't misclicked to "undo" instead "keep" button and didn't accidentally erase all the changes 🙈 Fortunately, AI doesn't judge and swiftly re-created the edit.

I spend some more time testing (and coming up with new refactoring ideas), but the job I was afraid to start was done.

The outcome

One evening, less than one hour, and the migration from vulnerable Nuxt frontend to more secured Nitro backend was completed. Most of the time I didn't write code, I was just reading and verifying what Copilot produced.

The task I didn't want to start was finished before it could bother me. It was fun, it was useful and it moved me forward. Just wonder how many more tasks like this wait ahead. Let's find out.

Nuxt Tutorial 8 - UI Integrations

Alois Sečkár — Sun, 11 Jan 2026 15:32:27 +0000

In the previous part we dealt with CSS; now we’ll move on to more advanced UI integrations. Just like with styling, you don’t necessarily need to reinvent the wheel. Instead of building every functional element from scratch, it’s usually easier to reach for a dedicated library.

We’ll go through four practical integration examples. The selection isn’t driven by any deep logic - these are simply technologies I’ve come across and needed them in my Nuxt projects. Still, they demonstrate some general techniques you can reuse if you ever need to integrate something similar. At the end of the article, you’ll also find links to ready-made integrations for other well-known UI libraries from the Vue ecosystem. Let’s dive in.

Bootstrap

Bootstrap used to be - and may still be - the most popular CSS framework for fast, responsive web development. It includes a set of predefined CSS classes, components, and JS plugins that make it easier to build modern design, responsive layouts, forms, navigation, and other interactive elements. It goes further than the previously covered Tailwind CSS, which focuses solely on styling.

Personally, I never really like it. If you’re starting today, I’d rather recommend combining Tailwind CSS with some library specialized in form controls (one of the next articles will cover those). But many developers are used to Bootstrap from earlier days, and of course Nuxt doesn’t prevent you from continuing to use it.

Nuxt integration

You can find some Bootstrap solutions in the Nuxt modules directory, but I had doubts about how up-to-date they are, so I chose a DIY approach via a Nuxt plugin. We haven’t covered plugins yet, but they’re an effective way to add new functionality to a base Nuxt app.

A quick explanatory aside: Nuxt plugin in this context is a file in the /app/plugins folder that can enrich the Nuxt instance - or even the underlying Vue.js app - via a dedicated function. Nuxt loads these files automatically and runs them at startup.

In your project you need dependencies on the NPM package bootstrap and on sass (similar to Open Props, you’ll need some extra CSS processing for your input stylesheet and this is the recommended way). Import Bootstrap styles in the main .scss file in /app/assets/:

/* /app/assets/main.scss */
@import 'bootstrap/scss/bootstrap';

In nuxt.config.ts we must register this file via css option:

// /nuxt.config.ts
export default defineNuxtConfig({
  css: ['~/assets/main.scss']
  // ...
})

Finally, we also need a plugin that provides interactivity to the Nuxt app via Bootstrap JS. These three lines will do:

// /app/plugins/Bootstrap.ts
export default defineNuxtPlugin((nuxtApp) => {
  nuxtApp.provide('bootstrap', import('bootstrap'))
})

The defineNuxtPlugin function is the handler mentioned above. Its callback receives the Nuxt app instance and lets you interact with it in various ways via its exposed API. For example, using provide you can provide everything that the bootstrap package offers through its exports.

You can find the source code of a simple example implementation here:
nuxt-bootstrap @ GitHub and see it in action.

DevExtreme

The DevExtreme UI library was first introduced to me by an “Angular guy” colleague. It’s framework agnostic though, so you can use it in Vue as well. The main downside is obvious right away: it’s paid — and not cheap. On the other hand, we used it on a larger real-world project at work, and I have to say building complex nested forms (assembled entirely from scratch) was incredibly smooth with DevExtreme. Their layouts also made it reasonably responsive. The documentation is high quality too, although it took me a bit to learn how to navigate through it.

Another small blemish is that for some reason Dx components don’t work with Server-Side Rendering - or at least, even after several years I never figured out what needed to be done. So you need to set ssr: false and accept that the app will render via JavaScript only in the client’s browser. That makes it more suitable for SPAs (Single Page Applications), where users treat the website more like a desktop application and are willing to wait a bit for the content to load - which was our case. For projects where loading speed and SEO are critical (typically e-shops), it might not be the best fit.

Nuxt integration

In package.json you need to reference the base NPM package devextreme and its Vue port devextreme-vue. That alone is enough for local development, but the problem is that “tree-shaking” (removing unused dependencies from the production build) doesn’t recognize you’re using its components, and it happily strips all the definitions out of the final bundle.

I struggled with this for quite a while and eventually had to get help. The key is, again, a Nuxt plugin where you gradually register the DevExtreme components you want to use as Vue components. I strongly recommend registering them under the same names DevExtreme uses — otherwise you lose the ability to easily search their documentation.

In this example I only use a basic button, but the principle is the same for everything else:

// /app/plugins/DevExtreme.ts
import { DxButton } from 'devextreme-vue/button'

export default defineNuxtPlugin((nuxtApp) => {
  nuxtApp.vueApp.component('DxButton', DxButton)
})

The DxButton component then becomes globally available in all your app’s component templates, and you can use it anywhere exactly as described in the DevExtreme documentation without additional constraints.

You can find the source code of the example implementation here:
nuxt-dx @ GitHub

After starting the app, you’ll notice a very prominent license warning in the header that DevExtreme injects into the unregistered version. That’s a reminder that without a purchased license, this integration won’t help you much. Still, we’ve demonstrated the general principle of using plugins to add any external Vue components into Nuxt.

FontAwesome

After general-purpose UI libraries, let’s move to FontAwesome, a popular solution for displaying icons on websites and in apps. It provides a wide selection of vector icons in SVG form (and also as font files) that you can easily use via CSS. FontAwesome allows simple manipulation of icons: changing size, color, and more.

“FA” used to be an evergreen in web design a few years ago, similar to Bootstrap. I think it’s past its peak too, but let’s still take a look. Since the time I solved the integration manually, a module has been created, so it may be easier today than what I describe below. My solution requires at least three new dependencies in package.json (more if you want to use icons from additional (paid!) sets), and overall it feels a bit clunky to me. But if you’re used to it and can list FontAwesome icon names off the top of your head, you can bring it into Nuxt with you.

The downside is that, like DevExtreme, FontAwesome doesn’t play nicely with Nuxt SSR, so you need to set ssr: false.

Nuxt integration

I integrated FA into a Nuxt project using a plugin again. This time it’s a bit less intuitive: you first extend the library object with the icon definitions you want to use, then take the FontAwesomeIcon object (from another FA package) and register it as a Vue component inside your app:

// /app/plugins/FontAwesome.ts
import {
  faEnvelope, faFaceSmile, faHouse
} from '@fortawesome/free-solid-svg-icons'
import { library } from '@fortawesome/fontawesome-svg-core'
import { FontAwesomeIcon } from '@fortawesome/vue-fontawesome'

// these icons will be available as values for the "icon" attribute
library.add(faEnvelope)
library.add(faFaceSmile)
library.add(faHouse)

// register the "fa" component
export default defineNuxtPlugin((nuxtApp) => {
  nuxtApp.vueApp.component('fa', FontAwesomeIcon)
})

In component templates you can then use the <fa> component like this:

<fa class="icon" icon="envelope" title="FA 'envelope' icon" />

You can find the source code of the example implementation here:
nuxt-fa @ GitHub

Icônes

Because I don’t consider the solution above particularly good, I’d like to immediately present an alternative. Icônes is a project focused on providing a large collection of icons for websites and apps. It offers a wide selection of SVG vector icons that are easy to use and customize. Icônes makes icon integration simpler and helps improve the visual quality of user interfaces.

If you ask me what to use for icons, I’ll recommend Icônes without hesitation. It gives you an easy way to get SVG-based definitions that are portable across environments, requires no new dependencies, and offers a huge library of icon definitions for free. In Nuxt - or rather, directly in Vue - you can introduce each icon as its own component. If you’re not using a UI library that handles icons in its own way (see e.g. the upcoming article about Nuxt UI), this is an excellent lightweight option that lets you use only what you actually need.

Nuxt integration

Unlike previous, this truly works without any external dependency. You simply find the icon you want on the Icônes website and export the source code directly as a Vue component. In my demo, three selected icons are copied this way into the /components folder.

You can find the source code of the example implementation here:
nuxt-icones @ GitHub

Universal icon component

You may have noticed (as I did) that these generated components look almost identical and differ only in their <svg> and <path> definitions.

In another project, I therefore have a component that renders one of predefined Icônes icons based on a definition from a data file. When the app needs a new icon, a new definition is added into the JSON file and linked from icon component. Feel free to use this idea as inspiration in your own projects.

Wrap up

In this article, we saw four examples of integrating external UI libraries into a Nuxt app. It’s definitely not an exhaustive list of your options, but I think it’s a solid starting point for inspiration.

In many cases, there’s already a ready-made Nuxt module for popular technologies that handles the integration for you. For example:

I don’t have personal experience with any of these, but you’ll surely find support in the active and friendly Nuxt community. And if you have a favorite CSS framework or UI library and you’re missing a Nuxt setup guide, reach me through a comment below and we can try to figure out the integration.

Next time, we’ll take a closer look at one more option that I intentionally left out so far - and also quickly adopted as my own: the Nuxt UI module directly from the Nuxt team.

New in Vue - December 2025

Alois Sečkár — Mon, 29 Dec 2025 15:14:09 +0000

Hi, everyone. This will be my 24th and last article in 2025. I wish you all a great start into the upcoming New year 2026 and before it happens, let's do this quick recap of latest development in the Vue / Nuxt / Vite world once again.

Vue will probably end 2025 in maintenance version 3.5.26. Vue v3.5 was released more than a year ago, so we can say the fundament of our ecosystem is pretty solid and stable right now. Bugs are being fixed, dependencies patched, and minor tweaks appear from time to time, but overall the code base has been settled and we can develop without worrying we will have to rebuild everything every few months.

I am not even aware of any ground-breaking changes under development, besides long anticipated Vapor mode, a new strategy for faster components' rendering. This will land in Vue 3.6 whose beta release appeared right before Christmas. If you want to know more, there is an article by Evan You himself. It was released in March though, so you can see the whole process takes its time.

I would say a solid portion of development effort was re-directed to Vite, the build tool originally designed for Vue which but overgrew into viable cornerstone of JavaScript development. And it is growing further as you can follow at the Void(0) blog page. Vite itself is now available in version 7.3 with upcoming v8 iterating towards the final release. Everything you need to know about Vite v8, is here.

Finally, Nuxt release cycle slowed down a bit in the last couple of weeks. Recent v4.2 is here with us for 2 months already with second patch release 4.2.2 being the last available version. Former v3 is still being maintained with backported version released together with v4 (3.20.2 is the most recent), but the scheduled EOL date (2026-01-31) is getting close. The relative stability is the good news, as it means other parts of the ecosystem as various modules may catch up and stabilize themselves around the latest releases too. Meanwhile, new major Nuxt version 5 is somewhere out there in the distance, probably closer than you fear, but farther then you hope. Or maybe vice versa, if you don't want to migrate again (though it is promised it should be easy and straightforward). Anyway, we'll see what happens in 2026.

Aside vanilla framework, Nuxt offers a number of wonderful modules to extend the core functionality. One of the most prominent official ones is Nuxt UI, the UI toolkit. The library keeps evolving, with latest version 4.3, that was released on 17th December. If you pick it for your next project, you may benefit from this practical guide about how to set up your IDE. Actually, you should check the article anyway, because many tips apply to Vue/Nuxt development in general. And I can confirm I was already using most of the extensions mentioned - they're valid and battle-tested.

If you want to receive ecosystem updates more often than once in a month, there are Weekly Vue News, an email newsletter being delivered each Monday. I certainly recommend you to subscribe, as I am getting a lot of inspirations from there.

Last but not least I want to spotlight a comprehensive NPM security guide composed by cybersecurity expert Liran Tal. In the woke of recent supply-chain attacks outbreak it is always good to remind and revise strategies to keep your projects safer.

Stay safe, have a great rest of 2025 and a successful start into 2026. See you again in the New year! 🫡

Upcoming events

VueJS Amsterdam 2026 - 12-13 March 2026, Amsterdam [NED]
Vueconf.US 2026 - 19-21 May 2026, Atlanta [USA]
MadVue 2026 - 22 May 2026, Madrid [ESP]

Past issues:

Follow me for more updates on Vue, Nuxt, Vite - and maybe even more!

Nuxt Tutorial 7 - Adopting CSS

Alois Sečkár — Sun, 21 Dec 2025 17:46:39 +0000

We already know how to get a Nuxt application up and running and how to use the various building blocks to assemble it. Now it's time to give our pages a reasonably decent look. In theory, we could handle that ourselves - using CSS styles defined inside the <style> sections of individual components. If you're confident with CSS, you can have a nice-looking website pretty quickly.

Most of the time, though, we don't want to rebuild everything from scratch. In this article you'll first see how easy it is to import ready-made CSS files, and then we'll go through two example integrations with projects that make styling much easier: Tailwind CSS and Open Props.

Import CSS

If you're migrating an older project, you might already have your .css style files ready. Or you may be using a service that ships its styles as a standalone .css file (i.e. when using Bootstrap from a CDN). Nuxt offers a very simple integration for these cases.

Upload your style files into the /app/assets folder (usually into /css sub-directory for better clarity). Then reference them via the css option in your nuxt.config.ts config file, i.e.:

export default defineNuxtConfig({
  css: ['~/assets/css/main.css']
  // ...
})

The imported styles are then automatically available across the whole application.

If needed, you can also load them individually per component - either in the <script setup> section:

<script setup lang="ts">
import '~/assets/css/main.css'
</script>

or inside <style>:

<style scoped>
@import url("~/assets/css/main.css");
</style>

Little sidenote: In example above I added scoped attribute to denote the style sheet should only be relevant for the component file itself. Otherwise the styles would leak globally. While this may be a bad thing, you can also do it on purpose (preferably in app.vue) and make your styles available throughout the whole application. More common is to use the css option in Nuxt config though.

Even with just this, you can achieve quite a lot. For examples of integrations with more advanced CSS libraries, keep reading.

Tailwind CSS

Tailwind CSS is a CSS framework for styling websites and applications. Unlike the traditional CSS approach, you don't write your own classes; instead, you compose the final look from a large set of predefined utility classes, which enables fast and flexible styling and layouts. Tailwind itself is also highly adaptable and configurable - for example when it comes to defining color schemes.

It deserves an article of its own (which I originally planned, and maybe I'll get to it eventually). For me it's currently the number one choice for building a website's look. It requires a slightly different philosophy, but I adjusted in a day, and I don't want to do it any other way now. I migrated couple of my personal projects to Tailwind CSS already, where the original design was done “by hand”. Converting them into the corresponding Tailwind structure usually took just one evening.

It's fair to note it's not a CSS framework “for purists” because it does impose some constraints. Others criticize it for creating too much abstraction and giving users the illusion that they understand what they're doing - until they hit a trap they can't resolve because they don't really know the underlying CSS. My experience, however, is that it will be enough in vast majority of situations, and its efficiency gives you more time to handle the remaining edge cases.

Nuxt integration

Getting started with Tailwind CSS is now very straightforward. The creators ship a plugin for Vite (the build tool Nuxt uses), which you just install together with the main library:

npm install tailwindcss @tailwindcss/vite

Then add the plugin to nuxt.config.ts along with a reference to the CSS file that imports Tailwind:

import tailwindcss from "@tailwindcss/vite";

export default defineNuxtConfig({
  // Vite integration plugin
  vite: {
    plugins: [
      tailwindcss(),
    ],
  },
  // CSS file importing Tailwind classes
  css: ['~/assets/css/tailwind.css']

  // other config...

});

The final step is creating a simple CSS file that you load via the css option. Its content can be as minimal as:

@import "tailwindcss";

Demo app

You can try the approach above in practice. The source code for the demo implementation is here: nuxt-tailwind @ GitHub

The demo focuses on both integration and usage. All the visual behavior is in /app/app.vue. It contains several examples of how Tailwind CSS can be applied. It also shows that utility classes can be freely combined with classic “plain” CSS. In /app/assets/css/tailwind.css you can see how easily you can extend Tailwind CSS' default @theme with your own colors or fonts if the base palette isn't enough.

Based on a personal bad experience, I also decided to add one cautionary example to the demo alongside the positive ones. I'm risking that it might inspire someone to use it and fall into the same trap I once did, but hopefully it will save many of you from unnecessary problems. What is it about? The Tailwind CSS authors encourage you to use utility classes directly in HTML templates as attributes on individual elements whenever possible. Not everyone (hi, former me) likes that, because:

Class lists can get really long
The same definitions repeat

At the same time, a beginner - armed with general programming truths and ready to “fix” things - will sooner or later discover the @apply directive, which seems to allow defining reusable classes in CSS files. And to be fair: it does allow it, and it works perfectly. The problem is that it severely obfuscates the implementation. After a few months, you forget you styled a <div> globally and wonder why your inline definitions don't apply. The demo app includes a clear example with the color of an HTML link at the bottom of the page. I wrote more about this in this article.

End of the diversion. Definitely take a look at Tailwind CSS - you might end up liking it like I do, along with thousands of other developers who prioritize speed and efficiency over perfect control via native CSS.

P.S.: Previously I handled the integration via a dedicated Nuxt module, which was a bit easier to set up (install + add the module). I'm not sure about its current status, though. After Tailwind v4 was released, it stopped working for me. Its new version has been stuck in beta for months, and it almost looks like its historical role is over. If the situation changes, I'll come back and update this article.

Open Props

Open Props is based on a similar idea to Tailwind CSS - it provides a set of prebuilt styles that may constrain you a bit, but in return you don't have to reinvent the wheel everywhere. Instead of shipping complete prebuilt CSS classes, Open Props encodes the styling information as CSS variables, which you can use and compose inside your own classes. To be honest: Tailwind v4 also uses CSS variables, and you may have already tasted them (even unknowingly) - see how the demo app extends the default @theme.

Open Props sits one level lower. It doesn't abstract away writing CSS entirely; it “only” provides ready-made, proven values. That gives you more freedom, but it's a bit more work. The main advantage is how lightweight and scalable it is - the library lets you use only the small subset you actually need.

Nuxt integration

Because Nuxt (Vue) can't replace CSS variables with actual values at build time by itself, you need to add a CSS processor (postcss in my demo) along with a plugin that performs the substitution after being fed the definitions from OpenProps. That's about the only catch; otherwise you just import the open-props NPM package and start building CSS definitions. There is a showcase of a few styles in the demo.

What I like most about Open Props are the ready-made gradients - smooth transitions between colors. Sure, it's not that hard to write them yourself in plain CSS (I even watched a demo of building a “gradient editor” recently), but if you're not a web designer at heart, who wants to grind through that?

The source code for the demo implementation is here:
nuxt-openprops @ GitHub

Summary

We've shown how to load internal and external CSS files into a Nuxt app, plus two examples of CSS libraries and how to integrate them. There are, of course, many other options. If you have a favorite UI/styling library, check whether it already has a Nuxt integration (most commonly in the form of a module). If not, it may be enough just to load the resulting CSS files the way we described at the start and use them directly. And if you get stuck, reach out and we can try to figure something out together.

In the upcoming tutorial article, we'll move from general styling to more advanced UI libraries, which provide not only styles but also prebuilt UI components. We'll look at a few of them along with examples of integrating them into Nuxt.

I made my Vitest suite in Nuxt run ten times faster

Alois Sečkár — Sat, 20 Dec 2025 11:21:08 +0000

Previously I had to wait about 3 minutes till my tests finish, now the same suite clocks under 20 seconds. Let's see what the bottleneck was and how I vibe coded the re-design. Spoiler: It was painful running in circles and despite AI gave me some valuable insights, I had to be the Deus ex Machina (pun intended).

I guess I don't have to explain the importance of writing automated tests to protect applications from introducing unnecessary errors. It is never 100%, but as the time flows, test suites grow larger, cover more situations and especially prevent bugs from re-appearing. I would say it is rather hard to develop a habit of writing tests regularly, especially in personal projects, but current tooling focus on making it easy. Setting up Vitest to test Nuxt applications is quick and you're good to go.

You can develop a new feature, write new tests for it, and run the suite to check if:

New tests are passing - so the new feature works as intended
Old tests are still passing - so you didn't accidentally break any seemingly unrelated things

Then you can commit with greater confidence.

But there is a catch - more tests run longer and former seconds may prolong to minutes. So you wait minutes and then you come back and see the test suite failed. You fix the error, run the tests again...and wait minutes again. Do this couple of times and you suddenly don't like the whole idea that much.

Framing the problem

Test suite for my Nuxt module for Neon database connection reached 180+ seconds of runtime. This didn't feel right anymore. The tests were testing, but the inefficiency hit my DevEx hard. It was the turning point when premature optimization turned into a required one.

Because it is 2025, I invited AI to check the situation and brainstorm for possible solutions.

Copilot quickly pointed out, that I am using separate Nuxt app instance for each test file. At first it looked like a good decision to separate concerns - testing SELECT operations in an app for selects, INSERT in another one. It should help keeping things small and organized. But booting them up takes time and all tests had to wait until their app is rendered.

To make the problem worse, I decided to run my tests sequentially. Because if something messes up and the module cannot even connect to the database, why tests the functions? Or if SELECTs are failing due to an error in constructing the SQL query, why to try INSERTs that would also inevitably fail? This stacks the waiting times up. And despite everything eventually works, I ended up waiting those 3 minutes.

First iteration - double speed

The fix was apparent - merge the separate test apps into one. This was quite easy to do, because I designed my tests so that each has its dedicated Nuxt page (this means separate URL) where it connects, perform SQL action bound to a button and check the resulting HTML for expected values. So I really just have to squash multiple /app/pages directories into one and make some small adjustments in app.vue file.

But it wasn't enough. Because my E2E test files would still

await setup({
  rootDir: fileURLToPath(new URL('./neon-test-app', import.meta.url)),
})

via a function from @nuxt/test-utils/e2e package. This would still create and bind new instance of Nuxt app for each test file. So it would still take a lot of time.

To be honest, there was already an observable speed-up. I guess it was because it can re-use some cached pieces and mounting the same app 5 times was about twice as fast as mounting 5 different apps, but it was still very sub-optimal.

What I really needed was that whenever any test case does

const page = await createPage()

it should connect to the same instance of underlying demo application. This would only start once and then all tests should call it with a snap.

Second iteration - 10x speed, but...

So how to do that? I didn't know. So I asked my smarter/dumber electronic assistant. It came up with very unorthodox solution. If you want to follow along, the result was committed HERE. I will now sum up the most important pieces.

In vitest.config.ts, new setting was added:

globalSetup: ['./node_modules/@nuxt/test-utils/dist/runtime/global-setup.mjs'],

It took me a while to understand what it is even intended to do. I challenged my Copilot's reasoning and cross-checked with my standalone ChatGPT 5.2 Plus. It confirmed the idea. Despite it testified it didn't find any article or discussion about it, it says it assumed from the code, it would work. The justification made sense. I had nothing to lose. So I believed.

In short, running this file in globalSetup before other Vitest actions start should "magically" grant me existence of a mounted app in emulated browser. To tell it, which app I want to mount, I should feed NUXT_TEST_OPTIONS environment variables which are swallowed during the process.

const rootDir = resolve(fileURLToPath(
  new URL('.', import.meta.url)), 'test/neon-test-app')

// Used by @nuxt/test-utils/runtime/global-setup
process.env.NUXT_TEST_OPTIONS = JSON.stringify({
  // path to neon-test-app
  rootDir,
  // don't create a Playwright browser in globalSetup
  browser: false,
})

The second integral part was e2e.setup.ts - a file to add actions to be run by Vitest before every test file. In beforeAll method it should construct a virtual browser instance - but only for the first time when it is non-existent:

const ctx = useTestContext()
if (!ctx.browser) {
  await createBrowser()
}

And just like that, this would grant all test files access to the shared context with prepared virtual browser with mounted Nuxt test app. And all tests should just:

const page = await createPage()

and start navigating to desired routes and testing the stuff.

I tried to follow my usual sceptical approach to AI and understand the intents behind the code spitted out - at least briefly. I couldn't grasp all details, but overall it appeared to make sense. And when I tried it - it worked!

Well, not for the first time. We had to tweak couple of things, but in the end the suite was running. And boy, it was fast! Less than 20 seconds and all tests already passed. If I deliberately made a test fail to check, whether it actually runs and tests something, it started failing just as expected. My job here was done. Commit, close the issue, go to sleep with good feeling.

Except there was a "tiny" detail I missed at the time. The Vitest suite was running fine, but once the process is finished, the output just disappeared from the terminal! So there was no chance to recover the result. Unless you looked at it, you had no chance to tell whether it passed or not. And if it failed, there was no way to see what exactly went wrong.

My tests essentially become useless 😨

Third iteration - to hell and back

The reason why I missed it when I worked on it is interesting per se.

Because we tried a number of things with my Copilot during the process, at some time we introduced $env:DEBUG='@nuxt/test-utils*' setting into my current terminal. Thanks to this extra environment setting, the program started to log differently - extensively and without interruption. All the log messages were prefixed with [source] tags, but I barely noticed that. I saw the Vitest output and I was happy.

But the default way of things with the globalSetup is, that the terminal is first occupied with the test Nuxt app build and then it is automatically switched into a new alternate screen that is visible in the terminal, but only as long as the associated process is running. Then it is just thrown away and replaced by former (empty) terminal.

I didn't know that, until I spend HOURS of useless attempts of adding config here and there. AI was spitting out fabricated theories, and I was struggling with implementing them and keep failing again and again.

After some time we at least isolate the DEBUG option as a possible workaround. But it also came with a very noisy and verbose output. Filtering out was possible, but platform-dependant. Or I could have wait for 20 seconds of silence and then got the filtered result processed by Node. Also not good.

I tried to bargain with AI until I finally - for the first time I thing - managed to force ChatGPT into saying: "No, this is not possible." More precisely, it wrote: "This is the moment where I need to be very explicit and honest, because you’ve now hit a hard boundary, not a missing trick." which I find hilarious now, but I didn't laugh back then.

The harsh truth hitting me that evening. I wasted hours chasing my own shadow. With AI happily assisting me and encouraging me to continue.

I have fast, but badly observable tests. Either no output at all, or an output littered by tons of non-related debug messages, or platform-dependant script commands to polish it.

Fourth iteration - deus ex homine

In my last article I went to sleep on the problem, and it didn't help. But this time it does. When I woke up this morning, prepared to finalize the ugly but so-so working solution, I suddenly got an out-of-the-box idea.

What if I stop trying to abuse Vitest into doing something it is not designed for?

What if I just aggregate my test files into one big suite?

Like that it would only need to build and mount the test app once and then it will run fast. Yes, there would be a little trade-off - one big test file with a lot of test cases. But to be honest, this doesn't really matter from the runtime perspective. And I can still keep the source code isolated by having separate definition files that will be dynamically imported in the actual single e2e.test.ts file, the only one that will be executed by Vitest.

And so just like that, I throw away most of the "clever hacks" from the solution #3 and came up with something else. Despite my AI assistants failed yesterday, I indeed used them again to help me fabricated the vivid solution. Now when I was back with a clear intention in mind, I got helpful output and tips again. The final solution is HERE.

Calls for globalSetup and even the setupFiles were removed from vitest.config.ts. The all I need now is a nice, small and clean e2e.test.ts file:

import { fileURLToPath } from 'node:url'
import { setup } from '@nuxt/test-utils/e2e'

// only setup nuxt-test-app ONCE
await setup({
  rootDir: fileURLToPath(new URL('../neon-test-app', import.meta.url)),
  // Playwright browser is not required for now
  browser: false,
})

// import and run E2E test suites AFTER the test app is ready
await import('../neon-test-suites/01-basic')
await import('../neon-test-suites/02-select')
await import('../neon-test-suites/03-insert')
await import('../neon-test-suites/04-update')
await import('../neon-test-suites/05-delete')

It prepares the Nuxt test app via dedicated setup function and then just awaits and executes one file with test definitions after another.

And that's it. No hacks, no mess in console. It works like charm and it is still fast. 20 seconds and you're done. The output remains in the console.

To infinity and beyond

So now you know how I wrestle with Vitest with Nuxt and won. If you'd like to know more details about the final implementation or you have objections and ideas for improvement, let me know in the comments.

You also seen how AI tools still lead you astray easily. To their defence, in this case both Copilot and ChatGPT pretty much resembled a common developer, who is desperately throwing solutions that "should work" without realizing the whole picture. Where they failed and I eventually succeeded was ability to step back and re-think the whole situation. I believe this is still the gap between human developers and the artificial pseudo-intelligence.

Lastly, this wasn't meant to be an anti-AI rant. It is helping me on daily basis, and I really enjoy getting further and further with its assistance. I just think there are still limits we need to be aware of. It was another nice lesson for me, and I hope you found it somewhat interesting too.

Looking forward to your feedback and questions.

The Mysterious Case of the Query that Never Ran

Alois Sečkár — Sat, 13 Dec 2025 09:54:47 +0000

Over the past weekend I encountered a weird bug.

I was refactoring code for my personal website. I am a casual runner and I have a page with all my run records. The data for it are stored in Neon database and I am reading them through my own custom nuxt-neon module.

I was updating the code to reflect the latest changes in my module. Namely I tried to change the filtering by date (year and/or month). Originally, I use literal string WHERE condition r.date BETWEEN '${fromDate}' AND '${toDate}'. Now I planned to battle-test my new object syntax:

where.push({ 
  column: 'r.date', 
  condition: '>=',
  value: fromDate,
});
where.push({ 
  column: 'r.date', 
  condition: '<=', 
  value: toDate, 
  operator: 'AND' 
});

Now, you may argue this is much more complicated and you'd probably be right. But I wanted to test how it works beyond sterile tests defined inside my module. And...

It was a complete failure.

No data. Just an ugly HTTP error when trying to get data from the Nuxt server endpoint:

NuxtNeonClientError in fetchFromNeonBackend: 
[POST] "/api/_neon/select": 400 Bad Request (status: 500).

To make a quick explanation - my module is providing a client-side composable useNeon that exposes couple of wrappers for SQL functions (namely select in this case). Those wrappers are essentially just forwarding input query to Nuxt server endpoints for each SQL function. Like this, I can keep the DB credentials safely stored on the server side and not leak them via runtime config into the browser. AFAIK Neon does not provide safe public API keys as services like Supabase do.

So I started to investigate what might be wrong.

At first, I thought I messed up the implementation, and I am constructing a bad SQL query. But there were two "buts" to this theory:

The very same query worked just fine when I reproduced it as a test case in my module codebase. And in fact, I was already testing whether "greater than / less than" operators pick the right data.
Despite I set enhanced debug logs for my module (you can debug both the execution flow and the actual SQL produced inside the module), I saw no data for my request. Actually, it looked like the API endpoint wasn't even called.

I found myself desperately tampering with the files inside my node_modules folder trying to track down where I am and why I am not seeing any usable output to understand the issue.

I had a faint suspicion that the literal characters > and < should be the root issue. But no viable theory of why it would matter.

I gave it a one-day break and unsurprisingly I didn't get any brilliant idea overnight. As a last resort, I just tried to ask my Copilot. I was postponing this move, because what would my question be? I don't understand what is going on, how should I instruct mindless LLM to come up with a solution? Without good prompt, I can't get good result, can I?

Well no, but actually yes. Copilot didn't magically save the day. But it gave me one important clue to follow: "Reproduce with curl (bypasses browser and frontend)"

This means, just call the API endpoint directly with a bare HTTP request. Strip it down from all frontend framework noise. Then you might understand better what is breaking up before backend can process your request. So I did as machine mind said and voilà!, everything clicked together.

Turned out my request was being rejected by Nuxt Security module and its XSS attack protection:

...\node_modules\.pnpm\nuxt-security@2.4.0_magicast@0.3.5_rollup@4.52.5\
node_modules\nuxt-security\dist\runtime\server\middleware\
xssValidator.js:38:18

Like that, it is pretty obvious. The problem was this particular line was swallowed inside Nuxt leaving me only with a cryptic error with no apparent reason.

Naturally, it was because of the > and < brackets. Nuxt Security treats them as potentially malicious attempt to smuggle a script into the payload. Between me and you - this module is pretty good in protecting your Nuxt applications with little to no effort of setting it up, but then it keeps biting you back like that.

So this was the missing piece. It worked in my tests because the naive demo app is not concerned about security that much. But I chose to shield my homepage with more advanced protection, and it backfired.

To mitigate the problem, I am adding an internal mapping that translates angle brackets to text abbreviations on client and back when constructing the actual SQL query on the server. For user convenience I decided to keep them available instead of forcing everyone to learn they should use GT and LT abstraction.

Despite the root cause and the solution itself isn't groundbreaking, I still thought the unique combination of circumstances is worth an article. I wanted to share following lessons learned from this debugging struggle:

Don't be shy to ask AI for help - Even if you don't know the right question yet, just ask: "Why do I have this error?" Start explaining the situation and you may vibedebug the solution eventually. It keeps surprising me how effective this becomes lately.
Isolate the problem - If backend seems not to respond properly, call it directly to abstract from possible interference. I should have known this after all those years in software development, yet I got lost in the frontend land and needed virtual assistant to pull me out.
Take 3rd party SW in account - Maybe it is not just your code that causes the trouble. Maybe some other library is acting up (because of something in your code).

I have been developing software for at least two decades now. I feel like a senior and being treated as such. But as you can see, I keep getting stuck in trivial situations and feeling rather stupid afterwards. I believe this is part of the process. You keep running into the walls, keep falling down and keep raising up, being ready for more.

Thank you for reading this and may it help someone in the future. Until the next awkward issue to solve.

New in Vue - November 2025

Alois Sečkár — Thu, 27 Nov 2025 13:21:49 +0000

Attention! More news and events from the ever-evolving world of Vue, Nuxt, Vite, and their awesome open-source ecosystems are there.

I would like to start 5th issue of my Vue newsletter with something I haven't done yet - sharing a video:

As you can see, it is a flashback from the ViteConf I was talking about last month. The reason why am I featuring this is interesting topic of not-so-distant future of our ecosystem together with the awesome stage presence of the speaker. I remember my very first impression was "Oh wow, the guy sounds quite nervous". But then Jim Dummet delivered one of the most memorable IT talk I can think about. The fact it was his only second live talk ever makes it even more awesome. Give it a try if you have a spare 30 minutes.

Speaking about ViteConf, two more interesting news I forgot to point out in October were released there. The Vite DevTools project was announced by Anthony Fu, which will bring the developer experience one more step (or even a leap) forward. Despite it seems nowhere near close to stable release yet, it is something worth paying attention to. And I am looking forward to the result. Second update came from Nitro - an alpha version of its v3 major upgrade was released during the conference by its maintainer Pooya Parsa. Also not finished yet, but another gamechanger in the ecosystem that is knocking at the door.

To get a comprehensive overview of what happened in Amsterdam (and should NOT stay in Amsterdam) was written by Alex Lichter, so if you want more detail plus direct links to respective talks, give it a go.

Overall November was quieter in terms of hot ecosystem news. Or they went past me if there were any. The one that hit me and I find it worth mentioning was the alpha release of Nuxt Hints module. It is promised to provide "real-time feedback on your application's performance, accessibility, and security right in your browser". I believe it will become very helpful to make our Nuxt apps better. It is out for two weeks now, and I am looking forward to set it up and give it a try. Sadly, there wasn't time for that yet.

Tiny promo (getting no commission for this, I just like it) - if you need an easy way of integrating Share with <<insert_socal_network>> buttons to your website, Nuxt Social Share is there for help. It is incredibly easy with zero knowledge of the APIs required - you just add a component, pick the target via a string prop and get the sharing functionality. I set it up within minutes for my blog. The "hardest" part is to adjust the default styling, but it uses Tailwind CSS, so it is actually not that hard at all. I really recommend this 👍

Did you ever feel overwhelmed by different approaches to managing stateful data in Vue applications? Michael Hoffmann wrote a useful guide for how to pick between Composables, Provide/Inject, and Pinia which might help you navigate through it. He also runs Weekly Vue News email newsletter, so consider subscribing for even more "New In Vue" stuff from him.

I'll be back in late December. Thank you for reading this and if you have any questions or feedback, feel free to use the comments bellow.

Upcoming events

VueJS Amsterdam 2026 - 12-13 March 2026, Amsterdam [NED]
Vueconf.US 2026 - 19-21 May 2026, Atlanta [USA]
MadVue 2026 - 22 May 2026, Madrid [ESP]

Past issues:

Follow me for more updates on Vue, Nuxt, Vite - and maybe even more!