Can a distro upgrade break your app?

Get Help and Help Others
1

I was working on my app, on some React components and all of a sudden it boomed:

../api/src/services/users/users.js Module not found: Error: Can't resolve 'src/lib/db' in '/Workspace/Code/redwood_test/api/src/services/users'

I hadn’t done anything critical nor meaningful for the past two days, hence the surprise.

The only thing I could see - however I don’t understand why it took some time, is that I upgraded to Ubuntu Focal Fossa, released a couple of days ago.

Directory and file exist.
I removed the migrations and reinstalled the db - just in case ;), nothing.
I ran yarn upgrade but i was already up to date.

Has anyone bumped into strange things after a distro upgrade?

2

Hi @noire.munich It’s possible but unlikely. There’s been more weirdness the last week in the NodeJS realm than anything. When you bumped distro versions, did you also update Node? (Note: definitely don’t run Node v14 at this time – it’s not working with Prisma last I checked.)

Couple things that would help diagnose here:

  • could you run yarn rw info and past the outputed system information here?
  • can you confirm you have db.js file at src/lib/db? What code is included?
  • can you copy the code from /api/src/services/users and paste here?

There have been changes to the db import (related to Prisma Client) between Redwood versions 0.3 and 0.4 (I believe). The RW generators were updated during that time as well. So it’s possible a service generated using a more recent version of Redwood could fail against an App codebase that was installed at an earlier version and not manually updated correctly.

3

Happened to me and it was the Node v14 problem @thedavid mentioned , although in addition to upgrading my distro I intentionally installed v14 to try out optional chaining/nullish coalescing. Prisma was not having it.

Reverting Node made everything go back to normal. If you don’t use it already, highly recommend nvm for that.

1 Like
4

Hello guys and thank you for your answers.

Unfortunately the node version should be viable, as yarn rw info points out:

  System:
    OS: Linux 5.4 Ubuntu 20.04 LTS (Focal Fossa)
    Shell: 5.8 - /usr/bin/zsh
  Binaries:
    Node: 13.14.0 - /tmp/yarn--1588321315762-0.6249029781481701/node
    Yarn: 1.22.4 - /tmp/yarn--1588321315762-0.6249029781481701/yarn
  Browsers:
    Chrome: 81.0.4044.129

Done in 1.46s.

db file is:

import { PrismaClient } from '@prisma/client'

export const db = new PrismaClient()

service file is:

import { db } from 'src/lib/db'
import { createToken } from 'src/services/tokens/tokens'

export const users = () => {
  return db.user.findMany()
}

export const userConfiguration = async ({ uid, token }) => {
  let user = await db.user.findOne({ where: { uid }, select: { id: true } })
  await createToken({ userId: user.id })
  return db.user.findOne({ where: { uid }, select: { handle: true, configuration: true, tokens: true } })
}

export const user = ({ id }) => {
  return db.user.findOne({
    where: { id }
  })
}

export const createUser = ({ input }) => {
  return db.user.create({
    data: input,
  })
}

export const updateUser = ({ id, input }) => {
  return db.user.update({
    data: input,
    where: { id },
  })
}

export const deleteUser = ({ id }) => {
  return db.user.delete({
    where: { id },
  })
}

To add a little context, I’m building an app with user content, so I need some auth and since there’s none and I need to grab content by identity, i have to stuff something up until the very much expected release that will provide auth support :). I went for firebase at the time and I’m still using it, I expect to change when auth will be supported :slight_smile:

thanks for the recommendation @dom, i’ll try it out. Which version of node are you using now?
@thedavid a couple of weeks ago I had an issue due to a raw bump from 0.2 to 0.6, to your instructions I made the needed corrections and it worked for a charm for a couple of days :), so I assume the issue is not related to my applying of the upgrade process. I suspected loaders but i wouldn’t know how to check. What do you think?

5

I’m using v13.12.0. Here’s the output from nvm ls:

        v7.10.1
->     v13.12.0
        v14.0.0

And here’s yarn rw info's output for good measure:

  System:
    OS: Linux 5.4 Ubuntu 20.04 LTS (Focal Fossa)
    Shell: 5.0.16 - /usr/bin/bash
  Binaries:
    Node: 13.12.0 - /tmp/yarn--1588327507672-0.6340345148114268/node
    Yarn: 1.22.4 - /tmp/yarn--1588327507672-0.6340345148114268/yarn
  Browsers:
    Chrome: 78.0.3904.108
    Firefox: 75.0
  npmPackages:
    @redwoodjs/core: ^0.6.0 => 0.6.0
1 Like
6

@noire.munich When upgrading the system, it can be possible to end up with issues in your installed node packages. (This happens with packages like gyp whenever I update Mac command line tools, for example.)

Try deleting your node_modules/ directory. Better yet, run git clean -fxd to remove everything represented in your .gitignore file. NOTE: this may result in loss of un-committed changes, so proceed with caution.

After that, reinstall with yarn install and see if that gets things working again.

7

For the sake of it, I went that way:
rm -rf node_modules api/node_modules web/node_modules yarn.lock web/yarn-error.log api/yarn-error.log

I kept the .env which seemed trivial ( only the database var ) and didn’t have the other directories/files mentionned in .gitignore.

I opterated on a copy I made of the project in a different directory, it did not work.

Eventually I thought to blame global installed modules, so I checked:

yarn global v1.22.4
info "create-react-app@3.0.1" has binaries:
   - create-react-app
info "create-redwood-app@0.6.0" has binaries:
   - create-redwood-app
info "eslint@6.8.0" has binaries:
   - eslint
info "react-scripts@3.4.1" has binaries:
   - react-scripts
Done in 18.98s.

I don’t see how any of these would affect the loading of the db, so it must be something else.

8

The db import is used to generate the Prisma Client, which does have complexity to it:

import { PrismaClient } from '@prisma/client'

export const db = new PrismaClient()

At this point, my guess is it’s Prisma lacking support for Ubuntu v20. I took a look at what they test against, and the most recent Ubuntu is v16. Here’s the list of platforms for binaries being tested. You might try to ask them directly via their Prisma GitHub Discussions.

Question:
Are you able to successfully spin up a new installation?

yarn create redwood-app my-directory
cd my-directory
yarn rw dev

If that doesn’t work, then there’s most likely something incompatible between Prisma and your system.

If that does work, then there’s likely something in your code causing the issue.

:thinking:

9

I’ve tried the new install: it works.

I have tried to migrate my code from the older app to the newly created app, it crashed, same bug, no clues.

I remove the import {db} from the service file, the error did not occur on page reload but remained in graphql queries.
Which led me to see that not all queries and services would fail, only the users.js and tokens.js services fail.

Next, I’m creating the db const directly in the services as it is done in the lib/db.js file, it now says
“Can’t resolve child_process”, which looks indeed as a prisma2 issue, covered up by the module loader unfortunately.

I’ll then follow your advice @thedavid and go to the prisma2 community, I suppose something is off in my schema due to the latest upgrades.

10

Sorry @noire.munich That’s just frustrating. I still don’t fully understand the error given the code you’ve pasted here. If you could possibly share a repo so I could reproduce the error, I’d be happy to give it a try.

re: Prisma
Yes, you would do well to look at the Release notes for Beta.1, 2, and 3. (Redwood is not yet using Beta.4.) And also look at their documentation for schema.prisma and Prisma Client CRUD.

Misc
I don’t think this is related, but there have been a lot of issues with the new version regarding schema.prisma datasource values and migration files. Maybe try deleting your dev.db and the migrations/ directory and then re-creating?

Last thought about blind debugging – try removing each function in users.js and see if you can isolate the error?

11

@thedavid I finally solved it!

Somehow by accident, the same way the issue was apparently caused.

It turns out that in web/ I had a SessionProvider component in which I found a very odd import:

import {userConfiguration} from '../../../../api/src/services/users/users'

This explains the error on the db const.

Now as said earlier I had a “Can’t resolve child_process” error, which again makes sense, Prisma2 client is not meant to be used in web/. That one got me confused because child_process is a reserved name for npm: https://www.npmjs.com/package/child_process

I was preparing a repo per your invitation and ended up having a look at the said React component and spotted an unused import ( odd as they are automatically cleaned ). That import was made straight away to the service, which explains why I had the error displayed in the browser during React rendering and not in the console or terminal as one would expect of a backend error ( a point that buzzed me and should have looked into a bit more earlier ).

I appreciate a lot your offer to have a look at a repo, this gave me the extra very needed motivation to look further myself :).

Bottom line is: the import was done because of how I configured the project in my IDE ( taking the global project and not splitting the workspaces ) and the fact that I had an exported const in each workspace with the same name.

12

Glad you figured it out!

But curious about why this didn’t show up as an error for you in the first place. What are you using for your IDE? And have you ever tried running the linter via yarn rw lint?

13

I’m using PhpStorm, I’ve reconfigured my IDE, now it’s properly set on using @redwoodjs/eslint-plugin
I hadn’t tried the linter through yarn, I’m still working this project up :). Now I have, this plus the tests I’m starting to implement and I should be set for a bright ride \o/

2 Likes
14

One of the things that might also help is to setup an alias to the src path, we do that for vscode over here:

1 Like
15

Yes indeed @peterp, I have it set up. It appears that PHPStorm detects it properly.