A follow-up to #4604: the dot in the regexp was not escaped as intended. By default `*` matches greedily, so the results are the same, but the new regexp should be more clear. Sorry for the mistake.
The prepares for next-server.
I also took this as an opportunity to get all build directory paths from a single location, as they were previously scattered across webpack/babel plugins and loaders.
Fixes#4572
This PR intends to address https://github.com/zeit/next.js/issues/4572 around documenting browser support and what needs polyfills.
There are many outstanding issues on the tracker regarding browser support and polyfills. This may alleviate some of them.
Fixes#4603.
Tests explain it the best:
```js
describe('development mode (no chunkhash)', () => {
it('should strip the extension from the filename', () => {
const filename = 'foo_bar_0123456789abcdef.js'
expect(getChunkNameFromFilename(filename, true)).toBe('foo_bar_0123456789abcdef')
})
it('should only strip the extension even if there\'s a hyphen in the name', () => {
const filename = 'foo-bar-0123456789abcdef.js'
expect(getChunkNameFromFilename(filename, true)).toBe('foo-bar-0123456789abcdef')
})
})
describe('production mode (with chunkhash)', () => {
it('should strip the hash from the filename', () => {
const filename = 'foo_bar_0123456789abcdef-0123456789abcdef.js'
expect(getChunkNameFromFilename(filename, false)).toBe('foo_bar_0123456789abcdef')
})
it('should only strip the part after the last hyphen in the filename', () => {
const filename = 'foo-bar-0123456789abcdef-0123456789abcdef.js'
expect(getChunkNameFromFilename(filename, false)).toBe('foo-bar-0123456789abcdef')
})
})
```
* remove `predeploy` scripts from `firebase.json` in favour of `npm` `pre` scripts as they are consistent across `deploy` and `serve` commands. (to revisit once Firebase add support in the `firebase.json` for `preserve`)
* update deps
* workaround some bug where Babel could not resolve the standard `next/babel` config. Explicitly defining this seems to remove the issue.
* closes#4562
This fixes a missed bug introduced in #4510.
Because the regexp was `/-[^-]*/` and not `/-[^-]*$/`, a wrong part of the filename was being removed:
```
bad:
'foo-bar-0123456789abcdef-0123456789abcdef.js' -> 'foo-0123456789abcdef-0123456789abcdef.js'
good:
'foo-bar-0123456789abcdef-0123456789abcdef.js' -> 'foo-bar-0123456789abcdef'
```
By a stroke of luck this didn't affect the existing dynamically generated chunks. To prevent regression I've added unit tests for the function that generates the name.
Btw. in the original issue (#4433) I used the right regexp, I just used the wrong regexp in #4510.
cc @timneutkens
Fixes one of the problems described in #4433.
The old regexp was removing everything after a hyphen, so with a chunk name like so:
```
chunks/path-to-a-file-[hash].js
```
the saved chunk name was
```
chunks/path
```
This caused problems, because webpack by default changes `/` to `-` in chunk names generated e.g. by ``import(`foo/${bar}`)``.
After this change the chunk name will be
```
chunks/path-to-a-file
```
Since `_app.js` is used on every page it makes sense to move it's dependencies to the `commons.js` so that if you require a dependency in `_app.js` and in one of your pages it is not included twice in your bundles.
This PR modifies the `CommonsChunkPlugin` to move every module that is used in `_app.js` and at least in one other bundle.
**Make amp example valid**
I'm using amp validator chrome plugin which shows that `meta charset=utf-8` is duplicated.
I assume that `Head` component adds `<meta charset="utf-8" class="next-head next-head">`
anyway.
And this line just duplicating it.
<img width="987" alt="screen shot 2018-06-06 at 15 54 45" src="https://user-images.githubusercontent.com/1488195/41036743-198ca00a-69a2-11e8-978c-5a5cb5a994d2.png">
Hello! I ran into an issue using typescript and jest with next 6.0.0. I was able to work through fixing it and I wanted to share my solution back to next.js, by upgrading the with-jest-typescript example to next 6.0.0.
The steps I followed were:
1. `npx babel-upgrade --write` which added babel-core@^7.0.0-bridge.0 to allow jest's babel 6 to play nice with next's babel 7
2. Remove `ts-jest` and replace with `babel-jest` to use babel to transform the typescript code, as is done when the dev and production builds run
3. Update the babelrc to use commonjs modules in test mode to be compatible with jest
Also, I removed the `NODE_ENV=test` on the jest task, because jest sets the env to test anyways, and I'm on windows where this code is incorrect. The other option is to use `cross-env` but I felt it was simpler to just remove the environment override.
To my knowledge, this PR would help on the following issues:
#3663#4227#4531#4528#4239
* Make router properties update when re-rendering
* Remove documentation about methods that have been deprecated since v2/v3
* Update next export documentation
resolves#4115
For now, I just added `'article:tag'` so it could be duplicated if we need more we have to extend:
```javascript
const ALLOWED_DUPLICATES = ['article:tag']
```
Previously we called this directory holding the pages/chunks for server rendering `.next/dist` instead of `.next/server` which is confusing both when looking at it and in the codebase, since there's also `distDir` as a configuration option.
Also made this a constant in `next/constants` so functionality using this can be easily found.
Allow `onClick` on `next/link` child. This should not be a breaking change, but it's a very useful feature. Real-life use cases include: analytics or closing menu on navigation, and other.
- [x] allow optional `onClick` on `next/link` component's child
- [x] call original `child.props.onClick(e)` before `this.linkClicked(e)`
- [x] add integration tests
- [x] cancel the navigation if `e.defaultPrevented === true`
Fixes#1490
This PR adds events for when there is a hash-only change in the URL. This is needed because `window.addEventListener('hashchange', ...)` does not work with next.js because it is using pushState.
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.
