* Add err.sh for image config errors
* Apply suggestions from code review
Co-authored-by: Steven <steven@ceriously.com>
Co-authored-by: Steven <steven@ceriously.com>
* Add err.sh for missing images domain
* Apply suggestions from code review
Co-authored-by: Steven <steven@ceriously.com>
* Update test
Co-authored-by: Steven <steven@ceriously.com>
Removes `next-head-count`, improving support for 3rd party libraries that insert or append new elements to `<head>`.
---
This is more or less what a solution with a `data-` attribute would look like, except that instead of directly searching for elements with that attribute, we serialize the elements expected in `<head>` and then find them/assume ownership of them during initialization (in a manner similar to React's reconciliation) based on their properties.
There are two main assumptions here:
1. Content is served with compression, so duplicate serialization of e.g. inline script or style tags doesn't have a meaningful impact. Storing a hash would be a potential optimization.
2. 3rd party libraries primarily only insert new, unique elements to head. Libraries trying to actively manage elements that overlap with those that Next.js claims ownership of will still be unsupported.
The reason for this roundabout approach is that I'd really like to avoid `data-` if possible, for maximum compatibility. Implicitly adding an attribute could be a breaking change for some class of tools or crawlers and makes it otherwise impossible to insert raw HTML into `<head>`. Adding an unexpected attribute is why the original `class="next-head"` approach was problematic in the first place!
That said, while I don't expect this to be more problematic than `next-head-count` (anything that would break in this new model also should have broken in the old model), if that does end up being the case, it might make sense to just bite the bullet.
Fixes#11012Closes#16707
---
cc @Timer @timneutkens
Warn users and revert their `devtool` when they manually change the `devtool` in development mode. For this addition, I check to ensure the `devtool` is custom (i.e. different than what is set by Next) and has a value (`false` is fine as a custom `devtool`!).
As described in [this issue (13963)](https://github.com/vercel/next.js/issues/13963), changing the `devtool` in development mode can cause issues with performance.
Fixes#13963
**First, apologies for a second PR on the same issue but I was working on this already so I thought I'd push it and let you decide which you want to merge.**
The PR is related to [13466](https://github.com/vercel/next.js/issues/13466).
Based on my research, the error happens if the options are empty, null, or undefined. That's why I have decided that the most proper check would be using the! post-fix expression operator may assert that its operand is non-null and non-undefined. ``if (options == null)``
(Optional)
I have also added a warning, which warns the user if the passed "dev" variable is not a boolean.
It's my first PR on the "packages" part of the repo so I'd be glad to receive all kinds of critics. If you want me to change or remove anything, I'm open to suggestions.
---
Fixes#13466
* Enable .env support by default
Given we've had tons of reports from various people that expected .env support to work even though they had dotenv installed already I think it's fine to enable it as a default:
Fixes#12728
* Remove old test
* Fix duplicate env loading
* Update docs
Co-authored-by: JJ Kasper <jj@jjsweb.site>
