This fixes the generated page chunk created by the webpack `pages-plugin` which adds a new line in the beginning of the template, when using `output.libraryTarget` set to be [`umd`](https://webpack.js.org/configuration/output/#module-definition-systems) it returns the module.
Consider the following example, which is the output with the previous implementation:
```js
(function webpackUniversalModuleDefinition(root, factory) {
if(typeof exports === 'object' && typeof module === 'object')
module.exports = factory();
else if(typeof define === 'function' && define.amd)
define([], factory);
else if(typeof exports === 'object')
exports["MyLibrary"] = factory();
else
root["MyLibrary"] = factory();
})(typeof self !== 'undefined' ? self : this, function() {
return
__NEXT_REGISTER_PAGE(...)
});
```
`__NEXT_REGISTER_PAGE()` won't be executed since a `return` statement followed by a new line is the same as having a semicolon inserted right after the `return`. By removing the new line in the beginning of the source concatenation (which I suppose was added for stylistic reasons) this works as expected.
* Don’t use chunkhash in development
* Add test for dynamic imports styling
* Remove pre-load of dynamic page
* Make sure the browser gets closed only once
When running some tests, I noticed that Akamai was still caching the
response for render errors for some reason. Honestly, I would've
thought that `no-store, must-revalidate` would be enough to prevent
the CDN from caching it.
That being said, MDN's documentation on [Cache-Control] has a section
called ["Preventing Caching"] and recommends also using the `no-cache`
directive.
Given the definitions provided for `no-cache` and `no-store`, I can't
tell much of a difference between these two. But I _do_ know that,
for whatever reason, Akamai seems to respect the `no-cache` value for
this header.
[Cache-Control]: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control
["Preventing Caching"]: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control#Preventing_caching
* Handle production errors correctly
* Improved source map support
* Make react-hot-loader hold state again
* Remove console.log
* Load modules on demand
* Catch errors in rewriteErrorTrace
* Update comment
* Update comment
* Remove source-map-support
* Load modules in next-dev
* Make sure error logged has sourcemaps too
* Add tests for production runtime errors
* Add tests for development runtime errors. Fix issue with client side errors in development
* Move functionality back to renderError now that error handling is consistent
* Rename to applySourcemaps
* Expose pages/_app.js
* Add tests for _app and _document
* Uncomment deprecation warnings
* Add documentation for _app, improve documentation of _document
* Update docs / test for _document
* Add _document to client compiler in development
* Add missing app.js to comment
* Only warn once
* Add url-deprecated error page
* Combine tests
* Yse same message for all methods of ‘props.url’
* Update docs around _app
* Update documentation
* Quotes
* Update table of contents
* Add build manifest
* Split out css since they don’t have exact name
* Remove pages map
* Fix locations test
* Re-run tests
* Get consistent open ports
* Fix static tests
* Add comment about Cache-Control header
* Allow BUILD_ID to be set in the environment
This makes multi server deploys with Capistrano possible.
* next.config.js generateBuildId support
enable customising the build id via config
* Provide default for generateBuildId
* This is not used
* Initial implementation of next export without exportPathMap
* Shorter message
* Set up flow
* Create pages manifest
* Use pagesManifest for next export
* Fix tests
* Document defaultPathMap
* Replacing the path is no longer needed
* Use posix normalize for consistent behaviour
* Remove second instance of examples
* Add comment about what pages-manifest does
* Make windows path a route
* Allow etags to be disabled with config option
- CR Change: Rename option to generateEtags
- CR Change: Add tests for etag generation
- CR Change: Refactor to use next.config.js
- Update documentation
* Use renderOpts instead of passing nextConfig
* Removed combine-assets-plugin, since its very broken
* Bundle everything into app.js on production build
* Clean up
* Removed app.js from server routes
* Renamed app.js -> main.js and removed commons from loading
* Remove commons and react CommonChunks
* Removed the commons route
* Killing the entire build-stats hack for app.js
* Removed unused md5-file package
* Add next/config
* Set config on server start / client render
* Add documentation for next/config
* Add next/config support for next export
* Fix test
* Use the correct name
* Set default to empty object on the client side
* Add config tests
* Rename config to runtimeConfig
* Fix SSR error handling.
* Remove unwanted console.logs
* Fix a typo.
* Fix current tests.
* Add a new test case for this case.
* Error should only be logged if it is not a 404
* Allow next.config.js to export a function
* Expose phases to the configuration function
* Use same value as variable name
* Add next/constants
* Add documentation for config function / phases
* Add constants.js to npm bundle
* Remove special error script handling.
As a result of that, we can't detect 500 errors and buildIdMismatch via client side.
* Fix failing test cases.
* Refactor the code base.
* Remove Router.onAppUpdated
* [SSR] Use relative paths in dynamic import output code
Now we use relative paths in the output code of dynamic import
in the server side.
* Remove unwanted constructor.
