Closed tbergquist-godaddy closed 4 years ago
Show your next.config.js please
next.config.js file can be seen here
Can you give more information about your setup? Do you own the transpiled files? Are you using flow? Why are flow files transpiled? Why are you transpiling an example repository? etc.
I am lacking some context on if this is the responsibility of next-transpile-modules
or next
Can you give more information about your setup?
We have a monorepo using yarn workspaces. We distribute several npm packages, among them some wrappers around relay. The relay example repository is there to show some examples of how to use relay. Mutations, paginations etc.
Do you own the transpiled files?
Yes
Are you using flow?
Yes
Why are flow files transpiled?
Because flow annotation is not valid javascript syntax, the flowtypes have to be stripped.
Why are you transpiling an example repository?
Same as above I would say. It needs to be transpiled to run in the browser.
At the end of the day, our setup worked with next 9.3.6
, and it broke when we upgrade to 9.4.0
.
Maybe it is not the responsibility of this package, but it is clear from the error message that our workspace is no longer transpiled, so that is why I started here.
Actually, I just discovered that doing yarn next build && yarn next start
works, while yarn next
produces the error 🤔
So the error might not be in next-transpile-modules
. It seems to be correctly transpiled for production.
could be interesting to check the changelogs of next, they may have modified the base Babel config, or there may have been a Webpack/Babel update.
Last: do you have a custom Babel config? If yes, can you post it here?
Yes, we have this babel config
module.exports = {
presets: ['@adeira/babel-preset-adeira', 'next/babel'],
plugins: ['relay'],
};
could be interesting to check the changelogs of next, they may have modified the base Babel config, or there may have been a Webpack/Babel update.
From reading the blog about the 9.4.0
release, the only thing I can think about is that somehow related, is the Import alias
functionality they added. Could it be that it interprets our workspace as an import alias 🤔
You don't have something for flow in your Babel config?
Yes, we do. This project has existed for about 3 years. There are no problems with Babel or other setup.
Something changed in next 9.4.0, and I suspected that something would need to change with next-transpile-modules also.
We "may" also be experiencing this issue. Just bumped to 9.4.x
and we are seeing issues around the new optional chaining language feature. We were using this prior to the upgrade, not code has changed. Our assumption is transpiration has stopped for some reason?
Also when we do next build
it works just next dev
Side note we are using Yarn v2
babel.config.js
:
module.exports = {
presets: [['next/babel']]
};
@andrewmclagan Can you share your Next config as well please?
$> yarn --version
2.0.0-rc.33
{
"next": "9.4.1",
"next-compose-plugins": "^2.2.0",
"next-transpile-modules": "^3.3.0"
}
const path = require('path');
const withPlugins = require('next-compose-plugins');
const transpileModules = require('next-transpile-modules');
const withModules = transpileModules([
'@pkg/mui-theme',
'@pkg/forms',
'@pkg/sdk',
'@pkg/client',
'@pkg/graphql'
]);
const nextConfig = {
webpack: config => {
config.resolve.alias['components'] = path.join(__dirname, 'src/components');
config.resolve.alias['dialogs'] = path.join(__dirname, 'src/dialogs');
config.resolve.alias['layouts'] = path.join(__dirname, 'src/layouts');
config.resolve.alias['forms'] = path.join(__dirname, 'src/forms');
config.resolve.alias['lib'] = path.join(__dirname, 'src/lib');
return config;
}
};
module.exports = withPlugins([withModules], nextConfig);
The packages are yarn workspaces (yarn 2)
/
- package.json
- /apps
- - /next-app-1
- - /next-app-2
- /packages
- - /graphql
- - /client
- - /sdk
- - /forms
- - /mui-theme
yarn workspace next-app-1 run dev
In reality we use scoped packages where our next websites are prepended with @app
and our packages with @pkg
so we would actually run
yarn workspace @app/app-1 run dev
So the below error is basically saying the optional chaining is invalid syntax, which if next is transpiling is not invalid. Thus my assumption that this package is the culprit? could be wrong!
> Using "webpackDevMiddleware" config function defined in default.
error - /Users/project/.yarn/$$virtual/@pkg-graphql-virtual-f0ee6be415/1/packages/graphql/hooks/useRole/useGet.js 10:20
Module parse failed: Unexpected token (10:20)
You may need an appropriate loader to handle this file type, currently no loaders are configured to process this file. See https://webpack.js.org/concepts#loaders
| });
|
> const role = data?.role;
|
| return { role, ...rest };
NB: On reflection this may be actually be a Yarn PnP issue. Perhaps opening a new issue is best, for now i will continue here.
If we keep all the above versions locked and simply use yarn 1.22
things work. Using either Yarn 2 or Yarn 1 with pnp (yarn 2 is default pnp) breaks. I have only very briefly looked at the source of this package although it seems allot depends on node_modules
folder resolutions. Which in a PnP environment does not exist.
Next officially supports PnP environments.
For me this is not related to Yarn PnP
since I am already using yarn 1.22.4
.
I made a small reproduction repo. You can check it out here. The master branch is using 9.4.x
, and the error is reproducable. There is a branch called 9.3.6
that is working with the same setup.
It looks a lot for me like a Babel misconfiguration. I will try to invest some time today or tomorrow to check that.
Thanks for the repro, it helps a lot!
It looks a lot for me like a Babel misconfiguration
I would buy this if it never worked, the thing that makes me think this is not it, is that it broke after upgrading.
I will try to invest some time today or tomorrow to check that.
Thanks, I appreciate that a lot 🙂
I would buy this if it never worked, the thing that makes me think this is not it, is that it broke after upgrading.
I buy it because the Next.js team always tweaks the internal and Webpack and Babel configuration in each release. We had breaking changes in the past because I don't read all the Next.js changelogs to see if the plugin needs to be updated or not (the CSS support for example, is extremely hacky, and could break at any canary release if they decide to change the shape of the Webpack rules)
tl,dr: next-transpile-modiles
hacks the internal Next.js webpack configuration to bypass the limitation of not being able to transpile code from node_modules
. Even a minor change to a include's regex or a rule option change from the Next.js team can break next-transpile-modules
without any warning.
Im having the same issues after upgrading to Next 9.4 😭
In our Yarn monorepo we have one app using next-transpile-modules 2.3.1 and that still works, but 3.0.0 in a next project fails, in case that helps with finding the issue, or people could downgrade while the issue is being resolved in 3.x.x.
Not the first time I hear that, thanks for sharing 🤔
I unfortunately still did not have time to look into the issue.
I personally did not have trouble in various Next.js 9.4 setups (with Yarn Workspaces), so for all the people landing on this issue, please share your setups specifities so we can try to identify the root of the problem more easily 👍 (the best of the best being a PR with a test failing)
I tried downgrading to 2.3.1
, but I still get the error. I also removed flow and tested with 100_000
and got the error
error - ../../node_modules/test-components/src/Heading.js:12:16
Syntax error: Support for the experimental syntax 'numericSeparator' isn't currently enabled (12:17)
And yes, we have the @babel/plugin-proposal-numeric-separator
in our babel setup
Next 9.4 implements its own alias system.
There has been changes to the webpack config that I suspect do not marry well with this plugin.
We use this plugin so to import files from other packages in a monorepo, I'm pretty sure there is no longer need for this plugin with 9.4 (for us at least).
We have this:
[
withTM,
{
transpileModules: [
'packages/core',
'packages/axl',
'packages/status-checker',
'packages/the-hub'
]
}
],
Use spoiler please
Actually I found the issue, it seems like the issue is with next-plugin-custom-babel-config
, not next-transpile-modules
. I noticed that rules are now
{
test: /\.(tsx|ts|js|mjs|jsx)$/,
include: [
'/Users/trondbergquist/code/privat/next-9.4-test/src/app',
/next[\\/]dist[\\/]next-server[\\/]lib/,
/next[\\/]dist[\\/]client/,
/next[\\/]dist[\\/]pages/,
/[\\/](strip-ansi|ansi-regex)[\\/]/
],
exclude: [Function: exclude],
use: [
'/Users/trondbergquist/code/privat/next-9.4-test/node_modules/@next/react-refresh-utils/loader.js',
{ loader: 'next-babel-loader', options: [Object] }
]
}
and next-plugin-custom-babel-config
tries to do rule.use.options.configFile = nextConfig.babelConfigFile;
which is probably why it works for production builds, since there is no react-fast-refresh
there
I can confirm it works now with next-plugin-custom-babel-config@1.0.3
, so feel free to close the issue @martpie
Great you managed to find the root of the issue! I'll be waiting on the confirmation of others and then we can close it 👍
We don't have next-plugin-custom-babel-config
anywhere in our project. It's a dependency of which package exactly?
"next": "9.4.2",
"next-compose-plugins": "^2.2.0",
"next-transpile-modules": "^3.3.0",
We don't have
next-plugin-custom-babel-config
anywhere in our project. It's a dependency of which package exactly?"next": "9.4.2", "next-compose-plugins": "^2.2.0", "next-transpile-modules": "^3.3.0",
It is its own package
OK. I removed this plugin from our repo and I'm getting exactly the same error as with it.
So clearly the issue is not with next-transpile-modules
for us.
Thank you for the feedback guys 👍
If anyone is passing by and the above "solutions" did not fix it for you, please comment :)
Hi,
I am still having this issue. The comment above pointed out its a plugin next-plugin-custom-babel-config that might be causing it. But I don't have this plugin installed and don't see a solution. Was anyone able to get working around this? I am on yarn berry, next 9.45 and next-transpile-modules 3.3.0.
Everything worked before the next upgrade, and I don't want to downgrade.
@andrewmclagan @nnennajohn Am also using Yarn 2 with Plug'n'Play and after banging my head against the wall for a couple weeks, finally been able to make some progress.
Firstly, I needed to change the workspace names passed to transpile-next-modules
to absolute paths instead. I.e. require('next-transpile-modules')(['@app/lib-next-utils']);
would become require('next-transpile-modules')(['/Users/runib/work/app/packages/libs/next-utils']);
.
Secondly, listing peerDependencies
in @app/lib-next-utils
breaks transpilation. If I omit all peer dependencies this plugin correctly transpiles the @app/lib-next-utils
workspace; adding any peer dependency back in and transpilation breaks again. Removing all peer dependencies isn't a solution though, at least not an appropriate one in my particular case. Have a feeling it's related to how PnP
works with dependencies/transitive dependencies
For me it fails with both next@9.4.0 as well as next@9.4.4, so the above may or may not be relevant in your case.
@RuniBr Thanks for the info. Unfortunately, I also run this in docker, so can't be hard-coding paths.
I think something changed in the latest nextjs, and this package needs to update to work with it. I got it working by following the hint above, and using next-plugin-transpile-modules instead.
I believe regarding the support for yarn v2 or yarn plug-and-play in general should be done in a seperate issue, not this issue. @nnennajohn @RuniBr
@andrewmclagan I mentioned it because I have used yarn v2 since it launched, and this package always worked with it. It only broke with the recent next update, so I don't think it's a yarn issue. Switching to next-plugin-transpile-modules got it working again.
@nnennajohn next-plugin-transpile-modules
is just the old package name of next-transpile-modules
, I would recommend you use next-transpile-modules@2
if you don't need to use the latest feature of v3 (CSS module, .mjs
etc), it has a lot of bugfixes that were not released under next-plugin-transpile-modules
(8.1.0 support, windows bugfixes, etc)
To anyone else snooping around: I think the original problem of this issue was fixed and looks unrelated to the problem you are facing, if you'd mind opening a separate issue, with clear reproduction steps, I could spend some time debugging it :)
edit: also, the best thing you can do to help is to provide a failing test 🙌
@martpie that's interesting. Because I thought I was on the latest. Will change it tonight and report back if I am able to get it working. Thank you.
Hey, not sure on status of this.. but i had the same issue.
Fixed by passing resolved absolute paths instead of package names, as mentioned above. ( on a very minimal config - next 9.4.0, yarn 1.22.4, next-transpile-modules 3.3.0 )
const path = require('path');
const withTM = require('next-transpile-modules')(
path.resolve( __dirname,'../../packages/ui/src'),
path.resolve(__dirname,'../../packages/ui-rendering/src')
);
module.exports = withTM();
I also declared paths in tsconfig.json using the same with next alias support. ( no babel config ) ( i still seemed to need the next-transpile-modules plugin )
Closing this in favor of #101 as it seems to be the root issue, and a workaround exists
I changed .babelrc
to babel.config.js
and it worked fine. :) - as it was mentioned on README.
Think it should be with a warning or something. It's easy to be missed.
Are you trying to transpile a local package or an npm package? local
Describe the bug Transpiling worked with next
9.3.6
, but broke after upgrading to9.4.0
.To Reproduce Upgrade from next 9.3.6 to 9.4.0 and transpiling of yarn workspaces breaks
Expected behavior It should still be working
Setup
next-transpile-modules
version: 3.3.0npm
/yarn
version: yarn 1.22.4Additional context Add any other context about the problem here.