Issue 1:
Problem

I am trying to implement h2 server push in my custom express server, but not able to figure out how exactly the path of bundled assets inside .next directory gets resolved on runtime.

Code

Currently, this is my server.js

const express = require('express');
const compression = require('compression');
const next = require('next');
const path = require('path');

const dev = process.env.NODE_ENV !== 'production';
const app = next({ dev });
const handle = app.getRequestHandler();
const cmdArgs = process.argv.slice(2);
const portNumber = parseInt(cmdArgs[0], 10);

app.prepare()
.then(() => {
const server = express();
server.use(compression());
server.get('/sw.js', (req, res) => app.serveStatic(req, res, path.resolve('./.next/sw.js')));
server.get('*', (req, res) => handle(req, res));
server.listen(portNumber, (err) => {
if (err) throw err;
console.log(`> Ready on https://localhost:${portNumber}`);
});
});

Basically I want to send my app.js bundle as soon as a hit is made on the root route.

So I am trying to achieve something like the code below by following this article:

....
....
app.prepare()
.then(() => {
const server = express();
server.use(compression());
server.get('/sw.js', (req, res) => app.serveStatic(req, res, path.resolve('./.next/sw.js')));
server.get('/', (req, res) => {
Promise.all([
fs.readFile(// path to index.html)),
fs.readFile(// path to app.js bundle),
]).then(files => {

if (res.push){
// The JS file
var squareRootStream = res.push(// path to app.js bundle, {
req: {'accept': '**/*'},
res: {'content-type': 'application/javascript'}
});

squareRootStream.on('error', err => {
console.log(err);
});

squareRootStream.end(files[1]);
}

res.writeHead(200);
res.end(files[0]);
}).catch(error => res.status(500).send(error.toString()));
});
});
server.get('*', (req, res) => handle(req, res));
});
....
....

Is it possible to implement something like this in next.js ?

Any advice/help would be greatly appreciated..!!

I have searched the issues of this repository and believe that this is not a duplicate.

Your Environment

Tech
Version

next
^3.0.1-beta.16

node
v6.8.0

OS
macOS

browser
Chrome Version 60.0.3112.113 (Official Build) (64-bit)

etc

Issue 2:
Bug report

Describe the bug

It is known that runtime config is not supported in static-optimized pages.

However, this repo demonstrates that even when runtime config is used only in server-rendered pages, the runtime config can still be missing, which is not expected.

To Reproduce

I have constructed a minimal demo app for the bug: https://github.com/MrOrz/nextjs-runtime-config-bug

This demo consists of 2 pages:

pages/index.js - A landing page that contains a link to data page. The page is meant to be static-optimized.

pages/data.js - The data page that depends on API_URL in public runtime config (Actually it prints publicRuntimeConfig.API_URL directly). This page is meant to be server-rendered.

Reproduction steps are:

Clone this repository & yarn

yarn build

API_URL=https://my.api yarn start and visit http://localhost:3000

Click "Data page" link on http://localhost:3000. Browser will navigate to http://localhost:3000/data without full reload.

Expected behavior

The /data page shows:

We show data from API URL: https://my.api

Actual behavior

The /data page shows:

We show data from API URL:

Runtime config "API_URL" in server-rendered page does not present.

However, if we visit http://localhost:3000/data directly, we can see the API URL again.

Screenshots

System information

OS: macOS

Browser (if applies) Google Chrome

next: 9.1.2

react: 16.11.0

react-dom: 16.11.0

Additional context

The scenario is the simplified from this website. I want to have a statically rendered landing page linking to a server-rendered article list; however, when users go to article list from the landing page, the HTTP requests always fail because API URL in config is not set.

When I deploy the website, I put the built website in Docker image. Production sites and staging sites will share the same docker image to ensure consistency between the two environments; the only difference between them are the API endpoints they connect to, which is specified in docker-compose file. This is why I put API URL in publicRuntimeConfig instead of build-time config.