-
Notifications
You must be signed in to change notification settings - Fork 27.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Added webpack dynamic import routes to the router. #742
Conversation
|
||
this.router.get('/_webpack/:number', async (req, res, params) => { | ||
if (isNaN(params.number)) throw new Error('Webpack dynamic imports should be numbered') | ||
const p = join(this.dir, `.next/${params.number}`) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should be join(this.dir, '.next', params.number)
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure, I'll change it
@@ -80,6 +80,13 @@ export default class Server { | |||
const p = join(__dirname, '..', 'client', ...(params.path || [])) | |||
await serveStatic(req, res, p) | |||
}) | |||
|
|||
this.router.get('/_webpack/:number', async (req, res, params) => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This path seems to conflict with https://github.com/zeit/next.js/blob/master/server/build/webpack.js#L179
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In what case?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I also am not sure exactly when this path is used, but some files, like patch files of HMR, are served from it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As far as I read #728, is this intentional ? Anyway it would be better to use a same logic to serve these files on dev and production IMO.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think here _webpack
is the path we exposed as publicPath
in the config.
I think in the dev mode, this is implemented by the webpack dev server itself. We only need to do this on production.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@arunoda makes sense
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So, shall we add this route only in the production mode? So we are sure, we don't interfere with the webpack dev server.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So with an if ( dev )
this should be ok @nkzawa ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Any thoughts?
@@ -80,6 +80,13 @@ export default class Server { | |||
const p = join(__dirname, '..', 'client', ...(params.path || [])) | |||
await serveStatic(req, res, p) | |||
}) | |||
|
|||
this.router.get('/_webpack/:number', async (req, res, params) => { | |||
if (isNaN(params.number)) throw new Error('Webpack dynamic imports should be numbered') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should respond with appropriate status code (404) ?
We are working on something similar on the |
@arunoda should we close this then? |
YEAH! |
Fixes #728
(and it's pretty cool)