> Workspaces are a new way to setup your package architecture that’s available by default starting from Yarn 1.0. It allows you to setup multiple packages in such a way that you only need to run yarn install once to install all of them in a single pass.
- [x] Tested in development mode
- [x] Tested in production mode
- [x] Tested with deployment https://with-yarn-workspaces-hwzubdlkul.now.sh/
- [x] Added transpile module example
Closes#3638
Pulling out a few core points from the readme...
This example builds from /src into /dist, managing the different expectations of express.js (es5, commonjs) and next.js (es6) by using a pair of tsconfig.json files, both of which are run by `npm run build-ts` or any of the other npm targets.
Hot module reloading is largely but not completely wired up (nodemon is watching /dist but tsc isn't set up to watch /src and transpile changes in /src to /dist automatically (that's mainly because I wasn't sure how to start both nodemon and a pair of tsc watchers and be confident all would get shut down when the user killed dev mode). The readme suggests running `npm run build-ts` manually in another window to push changes from /src into /dev and on into the browser.
tslint is also wired up via `npm run tslint`
The original example fails to compile on my windows machine but updating bs-platform fixes that.
Depending on bs-next causes example to fail (package compiled with old incompatible version of bs-platform) so I have included it in a bindings directory where it can serve as an example of reason bindings.
Sources have been migrated to the latest reason-react.
Running the [with-jest](https://github.com/zeit/next.js/tree/canary/examples/with-jest) example results in the following error:
```log
FAIL __tests__/index.test.js
● Test suite failed to run
SecurityError: localStorage is not available for opaque origins
at Window.get localStorage [as localStorage] (node_modules/jsdom/lib/jsdom/browser/Window.js:257:15)
at Array.forEach (<anonymous>)
Test Suites: 1 failed, 1 total
Tests: 0 total
Snapshots: 0 total
Time: 0.943s
Ran all test suites.
error Command failed with exit code 1.
```
Upgrading the dependencies (jest) to the latest version helps!
[More info](https://github.com/jsdom/jsdom/issues/2304)
Related #4776
* replace componentWillReceiveProps by componentDidUpdate
* replace props.url by withRouter HOC
* fix deprecated `props.url` in with-shallow-routing example
Fixes#4691Fixes#4614
This PR gives path to https://github.com/zeit/next-plugins/pull/242
I did not add or remove `^` near dependency versions in package.json files. However, I don't exclude that some changes can be made given that rc is more stable than beta.
Changes:
* Split `Header` component trough `_document.js` and `_app.js`
* Attached Router events with a way described in the [documentation](https://github.com/zeit/next.js#router-events) (though in the documentation is says it should be `Router.events.on` while I managed to get it working only by `Router.router.events.on` and I had to place it inside `componentDidMount`)
## Issue
Running [examples/with-custom-babel-config](https://github.com/zeit/next.js/tree/canary/examples/with-custom-babel-config) will result in the following error message:
```
./pages/index.js
Module build failed (from /some_path/next.js/dist/build/webpack/loaders/next-babel-loader.js):
Error: [BABEL] /some_path/next.js/examples/with-custom-babel-config/pages/index.js:
As of v7.0.0-beta.55, we've removed Babel's Stage presets.
Please consider reading our blog post on this decision at
https://babeljs.io/blog/2018/07/27/removing-babels-stage-presets
for more details. TL;DR is that it's more beneficial in the
long run to explicitly add which proposals to use.
...
```
## Explanation
Babel removed Babel's Stage presets on July 27, 2018.
More info: https://babeljs.io/blog/2018/07/27/removing-babels-stage-presets
## Solution
I've updated the example so ist just uses the babel plugin it actually needs.
## Related
Closes: #4772
Changes:
- Use css prop on the element to style it
- Add webpack + babelrc configuration to remove otherwise needed import boilerplate [according to glamor docs](https://github.com/threepointone/glamor/blob/master/docs/createElement.md)
Rationale: The killer feature of glamor that makes it so great is that it relieves you from naming classes/styles if you use the custom css prop. Together with the babel plugin you also don't need any extra import wherever the css prop is used.
All the real world uses I've seen of glamor has used the css props so I think the example should reflect this. As an example here is docs how to use glamor with gatsby (using the css prop):
https://www.gatsbyjs.org/docs/glamor/
Changes:
* moved the configuration from HOC to `_app.js`
* fixed the example, as `componentDidCatch` catches errors during rendering phase, but not within event handlers.
Changes:
* updated packages
* moved the content of `layout` to `_app.js` and created simple `Page` component
* replaced `import * as React` because it is not necessary to import everything
* moved `next.js.flow` to `flow-typed` as it is default directory for library definitions
* updated the gif
The existing example currently does not work because of outdated usage patterns. This PR seeks to update these patterns to the latest recommended best practice while bumping versions.
# Summary
- Bumped version numbers in `package.json`;
- Moved `<link />` tag from `pages/index.js` to `pages/_document.js` as is [recommended](https://github.com/zeit/next-plugins/tree/master/packages/next-css#usage);
- Replace individual css/font imports with import of minified CSS as is [recommended](https://react.semantic-ui.com/usage#semantic-ui-css-package);
- Removed prop (no longer used) from `<List />` element.
I’ve been experimenting with Next.js and Fastify and I made the following changes to the Fastify example based on what I found:
### Use Fastify’s plugin API
IMO putting Fastify’s listen call in a promise callback is an anti-pattern, b/c the Fastify plugin API is meant to solve the problem of async server bootstrapping.
[From Fastify’s Getting Started docs](https://www.fastify.io/docs/latest/Getting-Started/):
> Fastify provides a foundation that assists with the asynchronous bootstrapping of your application.
### Set reply.sent in handlers which return promises
[From Fastify’s Routes docs](https://www.fastify.io/docs/latest/Routes/#promise-resolution):
> If your handler is an `async` function or returns a promise, you should be aware of a special behaviour which is necessary to support the callback and promise control-flow. If the handler's promise is resolved with `undefined`, it will be ignored causing the request to hang and an *error* log to be emitted.
>
> 1. If you want to use `async/await` or promises but respond a value with `reply.send`:
> - **Don't** `return` any value.
> - **Don't** forget to call `reply.send`.
> 2. If you want to use `async/await` or promises:
> - **Don't** use `reply.send`.
> - **Don't** return `undefined`.
`app.render` returns a promise which contains undefined, so returning it in a Fastify handler will log an error. However, returning anything besides undefined will cause Fastify to try to write to the response which Next.js has already ended. The solution is to manually set the `reply.sent` flag to true when any Next.js rendering promise is fulfilled as an alternative to calling `reply.send`.
### Make Next.js handle 404 errors
This allows any route to throw a NotFound error and let Next.js handle the rendering of the 404 page.
### Make Next.js handle any route which starts with `_next` in dev
This prevents dev routes from being caught by user-defined routes.
As seen on `with-apollo-auth` there are some things that need to be addressed here too.
* #4554 remove useless `apolloState` from App props on `getDataFromTree`
* #4563 simplify `apolloState` prop
Let me know if further changes/fixes are needed.
Thank you 🎉
Updating to a more recent version of `@types/next` fixes an error I encountered while building a new app on top of the "with-typescript" example:
`Property `push` not found in SingletonRouter`
Additional context: https://github.com/DefinitelyTyped/DefinitelyTyped/issues/26665
To test, add a simple Router.push operation to the `pages/index.tsx`
```
import Router from 'next/router'
// ...
<span onClick={() => Router.push({ pathname: '/about' })}>TEST</span>
```
Apollo's getDataFromTree is supposed to be called during the server side rendering.
Being called in browser it fires an unnecessary fake render process and blocks components from rendering with loading=true.
Also there was a mistake in this code:
// `getDataFromTree` renders the component first, the client is passed off as a property.
// After that rendering is done using Next's normal rendering pipeline
this.apolloClient = props.apolloClient || initApollo(props.apolloState.data)
**Apollo** component is not rendered by getDataFromTree actually, it renders the **App** directly, thus props.apolloClient will always be undefined.
This example was discussed here: https://github.com/zeit/next.js/issues/387.
