Releases: gatsbyjs/gatsby
Don't start develop server if port in use & show friendlier error message
@crucialfelix raised two issues in #334 — a) it's hard to figure out to do when Node throws up it's cryptic EADDRINUSE error and b) Gatsby doesn't die as it should when it hits that but pretends it's running.
In #335 I fixed both where gatsby develop
now dies when the server can't start (for whatever reason) and when Node throws a EADDRINUSE error, we catch that, find the process that is listening on that port and show this error message:
We were unable to start Gatsby on port 8000 as there's already a process
listening on that port (PID: 43337). You can either use a different port
(e.g. gatsby develop --port 8001) or stop the process already listening
on your desired port.
Quick bug fix release
It turns out we need two stage types for development as adding HMR to the development server rendering the html.js
caused very obscure stack traces when there's errors in your html.js. Fixed in #305 by @benstepp.
Also @KyleAMathews added another small invariant to check what a user returns when they modify the Webpack config 58ea254.
Fix module resolve config
Quick release to fix the module resolve config to default to loading modules from Gatsby's node_modules
directory. This bug was introduced in 0.11.1 but shouldn't have affected most of you. See #299 for the full details.
Build performance improvements!
@benstepp made a number of tweaks to our default Webpack setup which dropped build times by ~30%! #294
Bug fix
@KyleAMathews fixed a bug where running gatsby --help
outside of a Gatsby site would erroneously show a warning 1fa7c4d
Inline CSS!
The headliner of this release is you can now inline CSS in the <head>
of your site. This is a best practice recommended by Google's AMP project among others as you then avoid additional requests which can signifcantly slow down your site. Testing using webpagetest.org showed that moving css inline improved the Speed Index 20-50%!! In one test on a simulated 3G connection, the time to initial render went from ~1.8 seconds to ~1 second.
It's a very simple switch to make. See this commit in the default starter gatsbyjs/gatsby-starter-default@1faecb5 It's also documented at https://github.com/gatsbyjs/gatsby#inline-css
Breaking changes
post-build.js
moved insidegatsby-node.js
. If you had added apost-build.js
module to your code, this function should now be exported fromgatsby-node.js
. A simple way to make the change is to simply requirepost-build.js
there e.g.exports.postBuild = require('./post-build')
. Thanks to @LukeSheard for this! #273- The "stages" were renamed. If you override Webpack configs and are switching behavior based on the stage,
static
is split into two stages,build-css
andbuild-html
andproduction
is nowbuild-javascript
. We think these are much more sensible names. Thanks to @scottnonnenberg for the this! #253
Other notable non-breaking changes
@benstepp did a deep refactor of how we're loading Babel plugins. There shouldn't be any breaking changes but it fixes a number of bugs #279
Some highlights:
- User can override the
.babelrc
passed to webpack. - User can use whatever babel plugins they want.
- User babel config is extended with
react-hmre
rather than being overwritten in develop.js. - Object.assign is now polyfilled by default.
- Non breaking change as starters previously required a babelrc and gatsby will just read them as normal.
- Fixes three issues #129, #235, #264
React 15!
Thanks to the efforts of @patrykkopycinski, Gatsby now supports React 15. This should be an easy upgrade for most people as long as your current site is showing deprecation warnings in the console.log. #252
@alampros also contributed a bug fix as he noticed that when setting the host option for gatsby develop
and gatsby serve-build
that the short version -h
overrode the default help option. He changed that to -H
so there would no longer be a conflict #247.
New --open flag, more tests, small bug fixes
@alampros added a --open
flag to gatsby develop
and gatsby serve-build
so Gatsby can now automatically open your site in your default browser. 09ea56a
@benstepp continued his testing ways and added integration tests for building pages with Markdown and HTML and added tests for the rewritePath
API. Great stuff! #240
@KyleAMathews fixed a bug where running gatsby --version
wasn't actually returning the version 😬 #249
Tests!, bug fixes, DX improvements
New tests!
@benstepp waded into the center of Gatsby and refactored one of the core functions AND setup a test framework AND added a number of tests. Awesome! #232
Bug fixes
- @BerkeleyTrue fixed route => template matching which was broken for some edge cases #230
- @BerkeleyTrue pointed out that errors in
gatsby-node.js
were being swallowed. @KyleAMathews fixed that in 859e412 - The Autoprefixer plugin was being added to the Postcss multiple times which @KyleAMathews fixed in dd2e960
Developer Experience (DX) improvements
- @michaeljdeeb added a check that hard-coded paths in pages have a path prefix. This is a problem that's bit several people as it's easy to miss #223. Invariants are awesome!
- @alehlopeh added a new cli command
gatsby serve-build
so you can easily check that your built site is working as expected. #237
Thanks everyone!
Babel 6! Require local install of Gatsby! 2500 stars!
Another release with two nice DX improvements.
Also we hit 2500 stars as I was writing this review 🎉
Babel 6
Gatsby started its life on Babel 5 but Babel 6 is out and stable so we'll upgrade along with the rest of the ecosystem and take advantage of its improved performance and awesome new plugin api.
Gatsby must now be installed as a dependency of the site
The global Gatsby install now defers to the local install of Gatsby (and throws if it can't find one). This means you can build a site and not worry about needing to upgrade it again as Gatsby accumulates breaking changes. This also helps ensure Gatsby works in environments where you don't want a global install e.g. build servers.
Upgrade instructions
- Install Gatsby —
npm install --save gatsby
- Install new Babel 6 dependencies (they must be installed locally) —
npm install --save babel-plugin-add-module-exports babel-preset-es2015 babel-preset-react babel-preset-stage-1
andnpm install --save-dev babel-preset-react-hmre
. - Uninstall old Babel 5 dependencies (if you added any).
- The
link
function fromgatsby-helpers.js
was renamed toprefixLink
to clarify its purpose. - Your
.babelrc
file needs to be upgraded to look like:
{
"presets": ['react', 'es2015', 'stage-1'],
"plugins": ['add-module-exports']
}
- If you modified the default Webpack config in
gatsby.config.js
, this functionality is now moved togatsby-node.js
and instead of using module.exports, export your config modification function asmodifyWebpackConfig
. See the updated instructions in the README. - If you were differentiating between pages with content (like .md files) and pages without (like pages/profile.js) by looking for truthy
page.data
, you'll now need check for truthypage.data.body
. - If your site is under version control, you might want to ignore the new auto-written module
.gatsby-context.js
. - rare if you used the
rewritePath
,onRouteChange
hooks in your app.js — app.js is now not supported. Instead you should exportrewritePath
ingatsby-node.js
andonRouteChange
ingatsby-browser.js
. The function signatures didn't change. These new files will be gaining more functionality in future releases.
That's it! See you in the issue queues :-)
Add support for JSON/YAML/TOML files + option to disable bundle.js for production build
- @KyleAMathews added support for creating pages from JSON/YAML/TOML files. This can be incredibly useful if you're integrating Gatsby with a 3rd-party system. Write out the data as JSON files and they'll be auto-converted into Gatsby pages. YAML & TOML are very handy for maintaining complex data for a page by hand.
- @scottnonnenberg added an option to disable building a
bundle.js
for production. This is helpful to minimize the amount of data people download for your site and for very large sites (e.g. 1000+ pages), not compiling the JS can save a considerable amount of time.