Ref: #33897
I took a naive approach and simply added `.env` to the files that need to be copied.
Do we want to include `.env.production` as well? Ref: https://nextjs.org/docs/basic-features/environment-variables#loading-environment-variables
(I haven't tested what happens if the file does not exist on copy.)
Other files like `.env.*local` or `.env.{test,development}` don't make sense to copy.
## 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`
Co-authored-by: JJ Kasper <22380829+ijjk@users.noreply.github.com>
We didn't port this plugin to next-swc given that the eslint setup warns for this automatically. Given that we still get issues opened for this particular warning coming from the plugin it'd be good to remove it.
## 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`
Fixes#27982
## 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
Partially solves #26539 by adding back the log output when a config file is used
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
## 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.
## Documentation / Examples
- [ ] Make sure the linting passes
## Bug
- [x] Related issues linked using `fixes #number`
- [x] Integration tests added
## 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.
## Documentation / Examples
- [ ] Make sure the linting passes
Fixes: https://github.com/vercel/next.js/issues/26163
Fixes an issue where "env" would be ignored and would crash if there was no top level "presets". Also found that webpack did not invalidate the cache on changes to the babel config, so I also fixed that.
* Try enabling Babel turbo mode
* Pass config file explicitly to babel turbo loader.
* Update NextBabelLoaderOptions to use `configFile` instead of `babelrc`.
* Re-add support for options passed to next/babel preset with new babel loader.
* Load babel config files depending on their file extension.
* Include `next/babel` if no Babel config is provided.
* Minor cleanup.
* Avoid duplicate `next/babel` entries.
* No need to pass configFile anymore.
* Fix multiple small issues in merging loader opts with cached config.
* Remove redundant logging (that also breaks a test).
* Include file extension CharacteristicsGermaneToCaching.
* bump
* Disable turboMode now that tests pass
Co-authored-by: Dale Bustad <dale@divmain.com>
This PR addresses the potential for memory leakage with the previous caching scheme; it should also be more efficient, resulting in fewer instances where a fresh Babel config must be generated. Documentation has been added, and `overrides` have been removed in favor of conditional plugins for consistency.
This approach is easier to break, in that `CharacteristicsGermaneToCaching` must be correct for all cases. However, it means that <= 8 configs will need to be generated within the context of a single thread, and the config-caching is about as fast as we can get it.
@timneutkens it'd be great to get your input.
These changes introduce a new Babel loader that eliminates much of the existing overhead, resulting in better HMR speeds.
Multithreading is still in flight, and may be omitted if speed improvements end up being negligible. For now, the new loader is hidden behind an `experimental` flag.
Items to be completed before this PR is ready to merge:
- [x] reconfigure `ncc` to precompile the parts of `@babel/core` and `@babel/traverse` that we're accessing directly
- [x] change `@babel/core/...` imports to `ncc`ed version
- [x] ~~measure multithreading (not currently pushed) functionality, and include the functionality depending on the results~~ I'll open a separate PR for this
- [x] ensure TypeScript is happy with all imports as final step (`--no-verify` was used to bypass)
There will be two follow-up PRs:
- loader support for projects with custom `.babelrc`
- multithreaded loader (should the change we warranted after measurement)
