Blitz: Blitz start --production rebuilds the app on Heroku

Created on 11 Aug 2020  路  11Comments  路  Source: blitz-js/blitz

What is the problem?

The blitz start --production command rebuilds the app during Heroku deployment even if it was previously built during Heroku's build phase. The application timeout on start after 60 seconds.

Steps to Reproduce

  1. create a new project blitz new blitz-heroku && cd blitz-heroku
  2. create a new heroku app heroku create
  3. create a root Procfile containing web: npx blitz start --production -p $PORT
  4. deploy to Heroku:
git add .
git commit -m "first commit"
git push heroku master
  1. go to https://your-app-name.herokuapp.com
  2. the app crash. You can see in the logs (heroku logs) that this is because of the start command timeout.

Versions

debug: blitzPkgPath: /Users/gabrielcolson/Documents/blitz-heroku/node_modules/blitz/dist/index.js
debug: cliPkgPath: /Users/gabrielcolson/Documents/blitz-realworld/node_modules/blitz/node_modules/@blitzjs/cli/lib/src/index.js

macOS Catalina | darwin-x64 | Node: v12.16.3

blitz: 0.17.0 (global)
blitz: 0.17.0 (local)

Other

The workaround I found was to replace the content of my Procfile by web: npx next start -p $PORT. It then worked perfectly.

kinbug statudone

Most helpful comment

This issue is happening because heroku adds .heroku and .profile.d folders.

Also, just to note, you can define a custom build script for heroku by adding heroku-postbuild script to package.json. For example:

"heroku-postbuild": "blitz db migrate && blitz build"

All 11 comments

Hey @gabrielcolson can you confirm that you ran blitz build during the Heroku build phase?

Assuming you did that, do you know how Heroku decides which files to copy to the runtime environment? I wonder if it's not copying both the .next and .blitz folders to the runtime image.

Hey @flybayer
Yes the blitz build is indeed executed we can see that in the logs.

I believe the output is copied "as is" to the runtime image after pruning the dev dependencies

Ok cool, someone just needs to dig into this and figure out exactly why our diff algorithm thinks the files are changed. (blitz start --production will re-use the built files unless it detects a change)

Is there a different lock file or something like that being added to the folder as part of the dev dependency removal?

If any files change aside from the following, blitz will trigger a rebuild:

node_modules
.blitz-build
.blitz
cypress
.next

@ryardley I couldn't say. I cannot ssh into the runtime container since it didn't even start.
I think we should take a look at the official node buildpack to understand what is going on there.

I had the same problem, but somehow I solved it by making the following changes to package.json. For your reference.

Edit: This allows me to start the server. However, the rebuilding itself was not stopped. sorry.

{
  "name": "examle",
  "version": "1.0.0",
  "scripts": {
    "start": "blitz start",
    "studio": "blitz db studio",
    "build": "blitz build",
    "lint": "eslint --ignore-path .gitignore --ext .js,.ts,.tsx .",
    "test": "jest",
-    "test:watch": "jest --watch"
+    "test:watch": "jest --watch",
+    "postinstall": "blitz db migrate"
  },
  "browserslist": [
    "defaults"
  ],
  "prettier": {
    "semi": false,
    "printWidth": 100
  },
  "husky": {
    "hooks": {
      "pre-commit": "lint-staged && pretty-quick --staged",
      "pre-push": "blitz test"
    }
  },
  "lint-staged": {
    "*.{js,ts,tsx}": [
      "eslint --fix"
    ]
  },
  "dependencies": {
    "@prisma/cli": "2.6.1",
    "@prisma/client": "2.6.1",
    "blitz": "0.21.1",
    "react": "0.0.0-experimental-7f28234f8",
    "react-dom": "0.0.0-experimental-7f28234f8",
    "react-error-boundary": "2.3.1",
    "secure-password": "4.0.0",
    "zod": "1.11.5",
    "final-form": "4.20.1",
    "react-final-form": "6.5.1"
  },
  "devDependencies": {
    "@testing-library/jest-dom": "5.11.4",
    "@testing-library/react": "10.4.9",
    "@testing-library/react-hooks": "3.4.1",
    "@types/jest": "26.0.13",
    "@types/react": "16.9.49",
    "@types/secure-password": "3.1.0",
    "@typescript-eslint/eslint-plugin": "3.10.2-alpha.16",
    "@typescript-eslint/parser": "3.10.2-alpha.16",
    "babel-eslint": "10.1.0",
    "eslint": "7.8.1",
    "eslint-config-react-app": "5.2.1",
    "eslint-plugin-flowtype": "5.2.0",
    "eslint-plugin-import": "2.22.0",
    "eslint-plugin-jsx-a11y": "6.3.1",
    "eslint-plugin-react": "7.20.6",
    "eslint-plugin-react-hooks": "4.1.0",
    "husky": "4.2.5",
    "jest": "26.4.2",
    "jest-environment-jsdom-fourteen": "1.0.1",
    "jest-watch-typeahead": "0.6.0",
    "react-test-renderer": "16.13.1",
    "lint-staged": "10.3.0",
    "prettier": "2.1.1",
    "pretty-quick": "2.0.2",
    "typescript": "3.9.7",
    "ts-jest": "26.3.0"
  },
  "private": true
}

Thanks @ia15076. That definitely works. How I usually do that is change the build script to include db migration.

 "build": "blitz db migrate && blitz build",

This issue is happening because heroku adds .heroku and .profile.d folders.

Also, just to note, you can define a custom build script for heroku by adding heroku-postbuild script to package.json. For example:

"heroku-postbuild": "blitz db migrate && blitz build"

@flybayer can we publish a canary version so that I can test this out?

@anteprimorac yes, will do!

it seems like heroku also creates .cache and .config folders during the build

Was this page helpful?
0 / 5 - 0 ratings