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.
blitz new blitz-heroku && cd blitz-herokuheroku createProcfile containing web: npx blitz start --production -p $PORTgit add .
git commit -m "first commit"
git push heroku master
heroku logs) that this is because of the start command timeout.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)
The workaround I found was to replace the content of my Procfile by web: npx next start -p $PORT. It then worked perfectly.
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
Most helpful comment
This issue is happening because heroku adds
.herokuand.profile.dfolders.Also, just to note, you can define a custom build script for heroku by adding
heroku-postbuildscript topackage.json. For example: