* converted guidelines containers from styled-system to theme-ui
* CopyColumn sticky styling fixed for responsive
* fixed the linting issue by converting double quotes to backtick
* guidelines design token page responsive layout fixed
* ContentColumn width changed for mobile
* used Flex from theme-ui instead of styled
* used the Box component from theme-ui inside Layout
* updated the breakpoints
* tweaking
* updated sections with no right padding
* styling updates
* created separate component for <td> with verticalAlignment of top
* added overflowX to the parent div of table on mobile
* fixed the lint error
* moved raw css to sx in containers
* fix: "Font Weights" token column value
`fontWeights[body]` -> `fontWeights.body`
* feat: add "px" column to "Font Sizes" table
Co-authored-by: Florian Kissling <florian.kissling@gmail.com>
* chore(gatsby): Switch query running to use services
* Fix typings
* Early return for empty queries
* Remove filesDirty
* Pass in graphqlRunner to services
* Pass in graphqlRunner into runPageQueries
* Pass in program to runStaticQueries and runPageQueries in develop
* Panic on missing store
* Remove unused props from context type
Co-authored-by: Sidhartha Chatterjee <me@sidharthachatterjee.com>
* perf(gatsby): drop severe scaling regression caused by analytics
Regression introduced in https://github.com/gatsbyjs/gatsby/pull/22851
The problem seems to be that these calls to `v8.serialize` trigger the gc to start a full hold-the-world mark-and-sweep step sooner. In a benchmark of 150k files, the step would trigger almost always after between 100k and 110k queries had run, and it would pause the process for 60+ seconds.
Example benchmark results from before and after that PR:
```
info bootstrap finished - 86.758 s
success Building production JavaScript and CSS bundles - 9.404s
success run queries - 205.676s - 150002/150002 729.31/s
success Building static HTML for pages - 142.800s - 150002/150002 1050.44/s
info Done building in 451.33 sec
```
```
info bootstrap finished - 85.933 s
success Building production JavaScript and CSS bundles - 8.335s
success run queries - 84.795s - 150002/150002 1769.00/s
success Building static HTML for pages - 141.000s - 150002/150002 1063.84/s
info Done building in 320.158 sec
```
This is very consistent behavior. We looked at the change and agreed that the best was to just drop this measurement since it was for the sake of analytics and a non-vital metric to record. We'd rather have the perf than the metric.
Numbers for the fix, same benchmark, first on current master and then on this PR:
```
info bootstrap finished - 79.788s
success Building production JavaScript and CSS bundles - 9.635s
success run queries - 201.542s - 150002/150002 744.27/s
success Building static HTML for pages - 141.535s - 150002/150002 1059.82/s
info Done building in 440.766 sec
```
```
info bootstrap finished - 80.751s
success Building production JavaScript and CSS bundles - 9.570s
success run queries - 87.162s - 150002/150002 1720.95/s
success Building static HTML for pages - 142.609s - 150002/150002 1051.84/s
info Done building in 319.151 sec
```
nice!
* And drop the import
* Change file extension from JS to TS
* Change reducer config export to ES6 module
* Change imports and exports to ES6 modules
* Change reducers import on redux index to use ES6 modules
* Update reducers imports and exports
* Comment unused codes
* Update merge conflicts
* Update nodesReducer module name
* Update last-action state type
* Fix merge conflicts
* Revert api test snapshot
* ops, actually fix merge conflicts
Co-authored-by: Michal Piechowiak <misiek.piechowiak@gmail.com>
GatsbyJS Bot