Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Next@10.0.2 breaks builds that rely on @babel/runtime being resolved relatively. #19448

Closed
RossMcMillan92 opened this issue Nov 23, 2020 · 2 comments · Fixed by #19538
Closed

Next@10.0.2 breaks builds that rely on @babel/runtime being resolved relatively. #19448

RossMcMillan92 opened this issue Nov 23, 2020 · 2 comments · Fixed by #19538
Assignees
@Timer
Milestone
iteration 15

Comments

@RossMcMillan92
Copy link

Bug report

Describe the bug

Next has changed the way it imports @babel/runtime

Next@10.0.1

var _interopRequireDefault = require("@babel/runtime/helpers/interopRequireDefault");

Next@10.0.2

var _interopRequireDefault = require("/home/USER/PROJECT/node_modules/@babel/runtime/helpers/interopRequireDefault");

This has broken our deployments, as we build on one image and deploy on a different one, which would require a different absolute path.

We now get MODULE_NOT_FOUND errors.

To Reproduce

Steps to reproduce the behavior, please provide code snippets or a repository:

  1. This happens by default on all Next.js builds

Expected behavior

@babel/runtime is required with a relative path, so we don't have to worry about external environment.

Screenshots

If applicable, add screenshots to help explain your problem.

System information

  • OS: Ubuntu (probably all OSes)
  • Browser (if applies) [e.g. chrome, safari]
  • Version of Next.js: 10.0.2
  • Version of Node.js: 12

Additional context
@RossMcMillan92 RossMcMillan92 added the bug Issue was opened via the bug report template. label Nov 23, 2020
@Timer Timer added kind: bug and removed bug Issue was opened via the bug report template. labels Nov 23, 2020
@timneutkens timneutkens added this to the iteration 14 milestone Nov 23, 2020
@merceyz merceyz mentioned this issue Nov 25, 2020
Merged
stipsan added a commit to stipsan/cocody.dev that referenced this issue Nov 28, 2020
@stipsan
Resolve next issue
3f72326 
vercel/next.js#19448
@Timer Timer self-assigned this Dec 31, 2020
@Timer
Copy link
Member

Timer commented Jan 2, 2021

Closing this as fixed by #19542

@Timer Timer closed this as completed Jan 2, 2021
kodiakhq bot pushed a commit that referenced this issue Jan 11, 2021
@merceyz
fix(next): always enable absoluteRuntime when running under webpack (#…
4e3eb73 
…19538)

**What's the problem this PR addresses?**

In #18921 I enabled `absoluteRuntime` for everyone (it was only enabled for PnP users) but didn't consider that people used the babel preset outside of the webpack build.

Fixes #19448 - ~~Since it doesn't contain a repro I can't be certain but based on feedback from @koshea in #18921 (comment) I'll assume @RossMcMillan92 is doing the same thing, because when next is building it doesn't leave absolute paths as external.~~
Confirmed in #18921 (comment)

**How did you fix it?**

Only enable `absoluteRuntime` when the preset is running under `babel-loader`
@balazsorban44
Copy link
Member

This issue has been automatically locked due to no recent activity. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you.

@vercel vercel locked as resolved and limited conversation to collaborators Jan 28, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees

@Timer Timer

Labels
None yet
Projects
None yet
Milestone
iteration 15
Development

Successfully merging a pull request may close this issue.

fix(next): always enable absoluteRuntime when running under webpack merceyz/next.js
4 participants
@Timer @RossMcMillan92 @timneutkens @balazsorban44