piglovesyou/graphql-let

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 (in transform)
  • in 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.