Usage with Next.js v12 and SWC as the compiler
rtrembecky opened this issue · 5 comments
Hi, I'd like to ask what is the correct way to use graphql-let
with Next.js v12, more specifically with SWC though.
What I've done:
- I had
babel.config.js
file at first - I ran
yarn build
- I was told by next.js that SWC is not used because of recognized babel config - I removed
babel.config.js
- I changed
jest.config.js
as suggested here - vercel/next.js#30811 (comment) - I ran
yarn build
again - This time, no warning from next.js build, so I guess SWC is used.
What I'm worried about:
My current next.config.js
looks somewhat like this:
module.exports = {
i18n,
pageExtensions: ["page.tsx"],
webpack(config, options) {
// taken from: https://github.com/vercel/next.js/blob/canary/examples/with-typescript-graphql/next.config.js
config.module.rules.push(
{
test: /\.graphql$/u,
exclude: /node_modules/u,
use: [options.defaultLoaders.babel, { loader: "graphql-let/loader" }],
},
{
test: /\.graphqls$/u,
exclude: /node_modules/u,
use: ["graphql-let/schema/loader"],
},
)
return config
},
}
I see the options.defaultLoaders.babel
entry (it is { loader: 'babel-loader', options: { presets: ['@babel/preset-typescript', '@babel/preset-react'] } }
entry in the graphql-let
docs), and I also believe graphql-let/loader
is using babel.
The question is:
Does it mean both SWC and Babel fire up when compiling the code? Does Babel jump in only to take care of .graphqls?
files, no it is OK in terms of performance? Is the next step in getting rid of Babel (and towards better performance) for this library to create an SWC-based transformer?
I'll continue with a related topic, which is the integration with Jest.
I think I figured this one out, so I want to share my Jest config here to help anybody who struggles with it. I'm using the new next/jest
package to bootstrap the config, but I still need to override something:
const nextJest = require("next/jest")
const createJestConfig = nextJest({ dir: "." })
// for reference, what's included and how the overrides work:
// https://github.com/vercel/next.js/blob/canary/packages/next/build/jest/jest.ts
const customJestConfig = {
moduleDirectories: ["node_modules", "src/test"],
moduleNameMapper: {
"@/components/(.*)": "<rootDir>/src/components/$1",
"@/features/(.*)": "<rootDir>/src/features/$1",
"@/graphql/(.*)": "<rootDir>/src/graphql/$1",
"@/pages/(.*)": "<rootDir>/src/pages/$1",
"@/theme/(.*)": "<rootDir>/src/theme/$1",
"@/utils/(.*)": "<rootDir>/src/utils/$1",
"@/test/(.*)": "<rootDir>/test/$1",
"@/toolsSetup/(.*)": "<rootDir>/toolsSetup/$1",
},
testEnvironment: "jsdom",
transform: {
"^.+\\.graphql$": [
"graphql-let/jestTransformer",
{ subsequentTransformer: "next/dist/build/swc/jest-transformer" },
],
},
setupFilesAfterEnv: ["<rootDir>/test/config/setupFiles.ts"],
// allow SWC to run on typescript code of generated types (to use schema model types)
// or cached types (to use enum's code), while still keeping mode_modules disabled
transformIgnorePatterns: ["node_modules/(?!@types/graphql-let|.cache/graphql-let)"],
testPathIgnorePatterns: ["<rootDir>/coverage/", "<rootDir>/test/e2e/"],
collectCoverageFrom: [
"src/**/*.{js,jsx,ts,tsx}",
"!**/*.stories.tsx",
// types (graphql, custom)
"!**/*.d.ts",
// example components, not used in production
"!**/examples/**",
],
}
const asyncConfig = createJestConfig(customJestConfig)
module.exports = async () => {
const config = await asyncConfig()
// next/jest ignores node_modules and allows to add more ignore patterns, but we need to override them fully to whitelist some node_modules
// https://github.com/vercel/next.js/blob/canary/packages/next/build/jest/jest.ts
config.transformIgnorePatterns = customJestConfig.transformIgnorePatterns
return config
}
For SWC, the important things are:
next/jest
automatically adds SWC as the compiler for js/ts/jsx/tsx (intransform
)- in
transform:
, for.graphql
files, thesubsequentTransformer
needs to be defined to use next's internal SWC Jest transformer
@rtrembecky Does your setup yield correct coverage reports for .ts*
files? I'm seeing incorrect line numbers and coverage %on a similar setup (typescript, next 12.0.7, jest 27.4.5, next/jest) and I have to bail out of the swc
transformer injected by next/jest
and use babel in order for sourcemaps to work correctly.
e.g. this gives proper coverage reports:
transform: {
'^.+\\.(js|jsx|ts|tsx)$': ['babel-jest', { presets: ['next/babel'] }],
},
@solomonhawk You're right. I don't check coverage in my project, but I tested it now and it's hugely off indeed.
@rtrembecky Did you ever get anywhere with this? I'm wanting to use .graphql files instead of gql`` tags in my .ts files. While I'm still locked in to babel (because I'm using emotion), I'd rather not add another thing that won't work with SWC.
@tettoffensive Hi, I can provide no update on this.