This avoids testing against latest exact canary version as this causes these tests to fail while the publish is still in progress. As a follow-up we can investigate moving this post publish or packing/deploying tarballs to use.
Co-authored-by: Steven <229881+styfle@users.noreply.github.com>
### Reason for making this change
https://yarnpkg.com/getting-started/qa#:~:text=yarn%2Finstall%2Dstate.,your%20workspaces%20all%20over%20again.
In the official documentation of `yarn`, it is stated that `.yarn/install-state.gz` is an optimization file that developer shouldn't ever have to commit. However, currently, when running `create-next-app`, `.yarn/install-state.gz` is being commited.
### Remaining work
I apologize for only modifying one template initially to initiate the discussion first.
If this change is agreed upon, it should be synchronized with other `.gitignore` templates. Would it be possible to follow a similar approach as in https://github.com/vercel/next.js/pull/47241? I would appreciate any assistance in syncing this change.
### What?
BREAKING CHANGE: Bump the minimum required Node.js version.
### Why?
Node.js 16 has reached end-of-life in September.
Bumped to `18.18.2` since it contained some security-related patches: https://nodejs.org/en/blog/vulnerability/october-2023-security-releases
### How?
Bumped `engines` where needed, upgraded the workflows.
This will allow us to remove quite a few polyfills, I'll open separate PRs for those.
### What?
This PR is pinning the installed versions of dependencies in `create-next-app`
### Why?
Currently, we write `latest` to `package.json`,
### How?
As far as I can tell, there is no way to update the `package.json` file based on the lockfile (which does have the information needed).
Major versions are bumped less frequently, so this should be fine to update manually.
Other alternatives would be:
- return to the previous way of running `npm i --save` and `npm i --save-dev` instead (ref: #55730). This might be slightly slower than one `npm i` pass though.
- fetch the latest versions of each package from the registry. Might be even slower
NOTE: The user has always the alternative to update the versions to their desired ones afterward.
Fixes#56174
