-
Notifications
You must be signed in to change notification settings - Fork 27k
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
Implement "on demand entries" #1111
Conversation
Otherwise it'll discard the use of dynamic-entries.
Why optional? |
No special reason. Since this is not the way how webpack works normally, some users may don't like this. So, we should implement this as |
This fixes #608 right? |
@timneutkens Yes. It's has the core. Let's make both related. |
client/on-demand-entries-client.js
Outdated
|
||
function ping () { | ||
const url = `/on-demand-entries-ping?page=${Router.pathname}` | ||
fetch(url) |
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.
What is this for ?
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.
That's to watch active entries and dispose inactive pages.
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.
Where is it implemented ? on-demand-entry-handler.js#middleware
is doing nothing ?
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.
Check now. I was implementing that :)
compilation.addEntry(context, dep, name, (err) => { | ||
if (err) return reject(err) | ||
resolve() | ||
}) |
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 we should not use private plugins.
Webpack v2 supports dynamic entries by setting a function to the entry
option. So what we'd like to do is to change returned entries according to page requests. I think we can do that with an optional entry function on server/build/webpack.js
.
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 is not a private function. It's documented by webpack.
Anyway, I'll try to use dynamic functions in the refactoring stage.
For now, this seems like the best option for now as we do more stuff related to entry management.
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 meant about plugins 'webpack/lib/DynamicEntryPlugin'. I'd like to fix that in this PR if possible or I will do it later.
9370d6b
to
d32c56a
Compare
After |
@timneutkens This is in 2.0. |
@arunoda ❤️ ❤️ ❤️ ❤️ ❤️ ❤️ ❤️ ❤️ ❤️ ❤️ ❤️ ❤️ ❤️ I hope you know that you're literally saving me and the ZEIT team a lot of valuable lifetime. |
timneutkens I think we can't wait that long :) |
Guys this is ready. Could you run this few tests before we merge in? |
server/on-demand-entry-handler.js
Outdated
dev, | ||
maxInactiveAge = 1000 * 25 | ||
}) { | ||
const server = await getServer() |
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.
Here we are starting a websocket server to accept pings.
The best idea is to hook into our existing app.
But with our API, we don't have access to the server object. So, we can't do that without changing the API.
Since this is dev only, it's fine to start a new server. Which is lightweight of course.
Why?
Earlier we did by sending a HTTP request from the client for every 5 secs. But those requests could be blocked at any time by the chrome for sending too much of requests.
And that could block HMR updates as well.
So, that's why we moved to WS.
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.
But those requests could be blocked at any time by the chrome for sending too much of requests.
Elaborate please?
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.
Chrome(and other browsers) has 6 concurrent connection limit for hosts. We won't send 6 connections but sometimes chrome set some of these requests into the stalled state.
May be it things we are sending too many requests.
Then it'll block the request which webpack asks for HMR changes time to time.
I couldn't find a better way other than using a Websocket connection.
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 Chrome sets it at 8 nowadays. Even then, we would only take up one socket ? Also, I believe webpack uses WS?
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.
Even then, we would only take up one socket ?
With HTTP2 yes it is. But it's not there always.
I believe webpack uses WS?
No it's not. It uses server sent events(HMR middleware) + 2 HTTP requests.
This reverts commit f706a49.
@@ -224,6 +224,10 @@ export default class Router extends EventEmitter { | |||
} | |||
|
|||
async prefetch (url) { | |||
// We don't add support for prefetch in the development mode. | |||
// If we do that, our on-demand-entries optimization won't performs better | |||
if (process.env.NODE_ENV === 'development') return |
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.
Some other places test with process.env.NODE_ENV !== 'production'
instead.
Developers might have forgotten to define process.env.NODE_ENV
but still expect to have a development behaviour in that case.
I think it would be nice if all the code tested whether it's in a production mode or not, in a coherent way.
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 wonder if we could use the dev
provided when setting up the app (server side). Not sure if we pass it through to the client side though, will allow for consistent behaviour not based on NODE_ENV.
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.
@sedubois we set NODE_ENV always. See: https://github.com/zeit/next.js/pull/1111/files#diff-0f2f34c098f5954f99483c9bd61e439dR94
We didn't use 'production' check here because, we need to allow prefetching in JEST.
So, this is safe.
It's mentioned that this should be opt-in/-out configurable, but I don't see any user documentation added in this PR. |
I'm wondering if that change causes a permanent recompiling of my application in development. It actually stops after 16 recompilations.
|
@DarKAdmiral a fix is coming. Beta 34 is on your way. |
client/on-demand-entries-client.js
Outdated
|
||
function ping () { | ||
const url = `/on-demand-entries-ping?page=${Router.pathname}` | ||
fetch(url) |
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.
(node:18740) DeprecationWarning: loaderUtils.parseQuery() received a non-string value which can be problematic, see webpack/loader-utils#56
parseQuery() will be replaced with getOptions() in the next major version of loader-utils.
i am recieving this warning can you tell me how to resolve this, this warning came when i've updated my 'next' version
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.
Can you create an issue for this?
So there is no 'opt-out' flag avail at this time? |
@mojo5000 nope. Currently there's no such flag. |
Related #608
This is a dev only optimization
This is new concept to reduce the dev-rebuild time dramatically if you have a lot of pages in your app.
With this, we don't add pages to webpack when building the dev server. But when we are accessing the page, we'll build the page and add it webpack.
With this, we were able to cut down "15 secs" dev re-build time to "1-2" secs.
TODO: