Since we are now using webpacks `mode` flag we can get rid of:
* `webpack.optimize.ModuleConcatenationPlugin`
* `webpack.DefinePlugin` (`process.env.NODE_ENV`)
https://webpack.js.org/concepts/mode/
* Add test for /_next/development route
* Make sure useFileSystemPublicRoute: false only disables filesystem routing
* Bring back comment
* Add useFileSystemPublicRoutes tests
Fixes#5125
I'm not sure if this is a bug in babel-loader / babel-core or not. But this will at least temporary fix it till I hear back from @loganfsmyth 🙏
you folks should really use semver ranges, but since greenkeeper
is no longer running for this branch things have fallen behind
in particular, there seems to be an incompatibility with multiple
v2.x versions of this package in the same bundle as displayed here:
https://github.com/styled-components/styled-components/issues/1972
When I force resolution to a particular h-n-r-s version, the issue
goes away. This is true for both next 6 and next 7 canary.
But really you folks should use semver carets instead of pinning.
you folks should really use semver ranges, but since greenkeeper
is no longer running for this branch things have fallen behind
in particular, there seems to be an incompatibility with multiple
v2.x versions of this package in the same bundle as displayed here:
styled-components/styled-components#1972
When I force resolution to a particular h-n-r-s version, the issue
goes away. This is true for both next 6 and next 7 canary.
Probably an oversight but currently env preset's `modules` option always evaluates to 'auto'. We probably want it to be set to false, especially in prod, to have Webpack handle modules natively.
Though it sounds like some folks do run getDataFromTree() on the client in order to avoid loading states, it's non-standard usage and potentially confusing. Also it's inconsistent with the other with-apollo examples.
The `with-flow` sample has some obsolete definitions which are unused by the sample code. Removing the un-imported declarations is the easiest approach.
Hi
In the current version of the example __custom-server-typescript__, types are never checked.
For instance, change the following line :
```
const dev = process.env.NODE_ENV !== 'production'
```
by :
```
const dev: number = process.env.NODE_ENV !== 'production'
```
then run `npm run dev`. The application launches perfectly, no error is thrown.
In dev environnement, it is preferable to check types all the time, to get immediate feedback. This PR activates type checking. Only when using nodemon, so no impact on production.
Now the above code will (rightfully) refuse to compile :
```
TSError: ⨯ Unable to compile TypeScript
server/index.ts (6,7): Type 'boolean' is not assignable to type 'number'
```
