Why dependencies matter? Deploy your Nuxt SSR (universal) app to Vercel Now.

patzick profile image Patryk Tomczyk ・4 min read

There are plenty of instructions on how to deploy your Nuxt application to Vercel. However, users with more demanding setup have a hard time to deploy their Nuxt applications quickly. One of these setups is universal mode, allowing to use Server Side Rendering, which can be a little tricky.

I want to deploy Now!

For those of you, who came here to get help with deploying the app quickly, there are two simple steps.

  1. Create an account on Vercel and give access to your repository.

  2. Add now.json file in root of your project:

  "version": 2,
  "builds": [
      "src": "nuxt.config.js",
      "use": "@nuxtjs/now-builder",
      "config": {}

And basically, that's it. Now Builder takes care of everything else and after the push, Vercel starts the deploy.

But at this point, you may experience two problems.

The first one is that the build script is not invoked - Now builder runs its own nuxt build step so that's something you may struggle with. Solution for this is to add now-build script to your package.json with anything you'd like to do before nuxt build is being invoked.

The other one is tougher - app deployment on Vercel terminates with the following message:

Error: The Serverless Function "index" is 82.5mb, which exceeds the maximum size limit of 50mb.

You must be thinking - What the heck? I wrote a light Nuxt application, how is this possible that it takes so much space?

This one is the actual reason why I started writing this article, so my thoughts on that later, now how to fix it?

I like simple tips, which are making a huge difference, this is one of them.

Move all your dependencies into devDependencies, remove yarn.lock file (or package-lock.json) and run yarn (or npm install) to regenerate a new one. Commit, push, and it's done.

As an example here's the repository, on which I wanted to deploy Shopware PWA to Vercel, but any Nuxt project with universal mode will work.

You may wonder why moving dependencies into devDependencies helped

So if you're still reading, we'll jump a little deeper into the subject. When you're learning about dependencies and devDependencies, the overall explanation is that dependencies should be used for packages, which are required during runtime, and devDependencies should contain those, which are used only for development.

Easy, simple, clear, but...

What does it mean that we need to use dependency at runtime?

Most often, it means that we have something like require('some-package') in our code. Node searches in node_modules for that package and includes it at the runtime. So you could deploy your node application to the server, run npm install --production and then npm would load into node_modules only packages from dependencies, and theirs dependencies (as of course required for runtime) and so on... As we all know node_modules can be huge. Running --production flag on node applications on servers makes sense.

It's not the case anymore with modern web applications though. We use bundlers now, we use ESM modules and importing things instead of requiring them. Nuxt is using Webpack under the hood, so everything necessary for the application to run is statically analyzed, propagated into chunks and transformed to build/ dist directories. There's no more calling node_modules on runtime.

All you're dependencies are devDependencies as are used only during build of your application.

And Vercel is following these rules. That's why even if your built application is maybe few MB it shows you enormous size - simply assume that you're dependency setup is used during runtime, so it's a part of the application size.

So when should I use dependencies in my web application?

Never :) Most of the time it's not important; most of the apps are not even using SSR, just simple uploads built dist folder to CDN. And for building, you'll load all the dependencies either way.

A little reminder for library authors

Everything you'll put into dependencies for your package will be loaded with the installation. Seems obvious, but sometimes people forget about that. It's not that you should not add there anything and build your lib now to contain all the necessary dependencies. It would cause code duplication as bundlers can't tell if it's your code or other lib used in the project as well. No one want's that. There's a simple rule for that.

My library needs for a user to have installed dependency X - if so, we don't want to write in our quick start section "Install X,Y,Z in order to run". We're adding them to dependencies section, and until they are needed to run your lib, it's their place.

How contributors may help with that?

Jump into Open Source projects. Check out dependencies sections of their packages. Confront them with code. It usually doesn't require in-depth project knowledge. Maybe try Bundlephobia to see if any of these dependencies have a lighter alternative in the Similar Packages section.

Try to help by providing a PR, if it's complicated, you may create an Issue where you can discuss your findings. There's no point of any kind of shaming that your package has this HUGE dependency. Be polite; everyone's doing their best.

Posted on May 24 by:

patzick profile

Patryk Tomczyk


Technology Leader @ Shopware PWA


markdown guide