This ensures we don't add non-es5 code from ncc'ing
Fixes: https://github.com/vercel/next.js/issues/30450
## Bug
- [x] Related issues linked using `fixes #number`
- [x] Integration tests added
- [x] Errors have helpful link attached, see `contributing.md`
fallback to alternative external version also when it fails because of base resolve mismatch#
fix resolved .mjs modules treated as external
fixes#30330
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have helpful link attached, see `contributing.md`
## Feature
- [ ] Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR.
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have helpful link attached, see `contributing.md`
## Documentation / Examples
- [ ] Make sure the linting passes by running `yarn lint`
This includes
- https://github.com/swc-project/swc/pull/2530
- Strip out `declare`-d class properties properly.
- https://github.com/swc-project/swc/pull/2538
- Marks method properties as a scope while renaming variables.
- Fix regression of object-rest pattern handler.
- Improve name mangler a bit, by marking it as a scope.
- https://github.com/swc-project/swc/pull/2551
- Fix a bug of the property inlining pass which can break many react apps.
There is a minor regression in the minifier due to added aliasing check.
(I manually selected crates to update)
A tsconfig like:
```
{
"extends": "..."
}
```
currently fails the build if the config that is extended from has not the expected configuration (and we want to update it)
Fixes: https://github.com/vercel/next.js/issues/30360
I used `create-next-app` to create a new fancy Next 12 app, ran `yarn build` and got a git diff. The tsconfig.json had a `incremental` added by next. Just running build shouldn't need I have uncommitted changes.
We found that `.swcrc` was unintentionally loaded breaking applications as it is not tested for that yet, customization will be added at a later point in time
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have helpful link attached, see `contributing.md`
## Feature
- [ ] Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR.
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have helpful link attached, see `contributing.md`
## Documentation / Examples
- [ ] Make sure the linting passes by running `yarn lint`
When an compilation happens in the timespan between "page loaded client bundle" and "web socket got initial sync event" it didn't apply the hmr update.
This ensures we remove null bytes from the resolved path as it isn't valid when using `path`/`fs`. Additional tests have been added to ensure this is handled properly.
## Bug
- [x] Related issues linked using `fixes #number`
- [x] Integration tests added
- [x] Errors have helpful link attached, see `contributing.md`
Fixes: https://github.com/vercel/next.js/issues/30298
In #29010, we started throwing an error if the res was mutated after
getServerSideProps() returned. This was to support classic streaming,
where it would be possible to accidentally mutate the response headers
after they were already sent. However, this change also caught [a few
non-streaming cases](https://github.com/vercel/next.js/pull/29010#issuecomment-943482743) that we don't want to break.
As such, with this change, we only throw the error if res is mutated
after gSSP returns *and* you've opted into using classic streaming.
Otherwise, we will only add a warning to the console.
