-
Notifications
You must be signed in to change notification settings - Fork 10.3k
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
[1.0] make determining when a given stage is finished much more reliable #1080
Conversation
Deploy preview ready! Built with commit 42804c1 |
Oh and I also added support to the API runner for callback based async. So you can now either return a promise or use the optional third callback argument. |
Deploy preview failed. Built with commit 793119b https://app.netlify.com/sites/using-postcss-sass/deploys/59303449cf321c04c3ac20e3 |
Deploy preview failed. Built with commit 793119b https://app.netlify.com/sites/image-processing/deploys/59303449cf321c04c3ac20e8 |
Deploy preview failed. Built with commit 793119b https://app.netlify.com/sites/gatsbygram/deploys/59303448cf321c04c3ac20dc |
Deploy preview failed. Built with commit 793119b https://app.netlify.com/sites/gatsbyjs/deploys/59303448cf321c04c3ac20da |
Deploy preview failed. Built with commit 6d10258 https://app.netlify.com/sites/using-postcss-sass/deploys/59303e21424ef20be0332dd3 |
Deploy preview ready! Built with commit 42804c1 |
Deploy preview ready! Built with commit 42804c1 |
this is sweet! Should make wrangling console output a lot more straightforward as well :) I can't wait to try on top of this |
Deploy preview failed. Built with commit 6d10258 https://app.netlify.com/sites/image-processing/deploys/59303e21424ef20be0332dd8 |
// This fails in tests. | ||
let actions | ||
try { | ||
actions = require(`gatsby/dist/redux/actions`) |
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.
could use Jest moduleMapper to rewrite these paths back to src
in tests
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.
👍 done
…ble (gatsbyjs#1080) * Use 'traceId' to track when cascading actions are complete * Add jobs system + move query running into internal plugins * Fixes, remove logging, disable rebuilding schema in dev * Remove unused code/packages * Rename variables * Update snapshots * Fix building + change postBuild to onPostBuild * Fix Drupal source plugin/site by restoring way for plugins to set status + touchNode action creator * Remove console.logs * debugging * Use jest moduleNameMapper to fix failing test * Don't query raw field as we don't use it * Use standard JSDoc notation
Two main tricks.
One was adding a way to track cascading work e.g. a source plugin adds a node which then transformer plugin takes and creates a new node which then another transformer plugin does more work on and so forth. Before there was no way to know when the last bit of work associated with the initial sourcing was finished. To solve this, I added a
traceId
which is passed in during the original API call and then all subsequent work passes it along. And rather nicely, this is all hidden from the plugins themselves as we inject the traceId into the actions that plugins create.Second was moving more internal work into internal plugins. This lets us take advantage of the new tracing capabilities above so that if internal work is triggered by an API call, we're tracking it along with every other plugin.
Now the bootstrap/index.js file is quite straightforward to read especially with our use of async/await. It's now stepping cleanly through each step of the process.
This solves two problems. The biggest is there was occasionally weird graphql errors where some data just wouldn't get processed in time before the debounce timeout. Those should be gone now. The other is the debouncing added time overhead to the bootstrap process. Removing that means bootstrap is sped up by something like 750-1000 milliseconds. Now a barebones Gatsby site's bootstrap can be as fast as 2.5-3 seconds (And most of that time is loading JavaScript so can't wait for prepack.io to get prod ready).
I also snuck in a simple jobs system. gatsby-plugin-sharp (image processing plugin) is the only user atm but it let's plugins tell Gatsby it has long-running jobs going and block bootstrap from finishing while it's working. It should have all the data necessary for building a nice CLI UI @jquense