Open rtrembecky opened 2 years ago
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 (in transform
)transform:
, for .graphql
files, the subsequentTransformer
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.
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:
babel.config.js
file at firstyarn build
- I was told by next.js that SWC is not used because of recognized babel configbabel.config.js
jest.config.js
as suggested here - https://github.com/vercel/next.js/issues/30811#issuecomment-963102661yarn 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:I see the
options.defaultLoaders.babel
entry (it is{ loader: 'babel-loader', options: { presets: ['@babel/preset-typescript', '@babel/preset-react'] } }
entry in thegraphql-let
docs), and I also believegraphql-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?