danielwaltz / vite-plugin-graphql-codegen

Zero-config vite plugin that uses the vite file watcher to run graphql codegen programmatically without needing to start a separate watcher
https://www.npmjs.com/package/vite-plugin-graphql-codegen
MIT License
82 stars 7 forks source link

TypeError: codegen is not a function #4

Closed sharmapukar217 closed 2 years ago

danielwaltz commented 2 years ago

Hey @sharmapukar217, any additional information you could provide on this? I haven't experienced a similar error message to this myself yet.

arabold commented 2 years ago

Was just trying out this plugin for the first time as well and I don't really have much Vite experience either. But I'm running into the same error. My config looks like this:

import react from "@vitejs/plugin-react";
import path from "path";
import { defineConfig } from "vite";
import codegen from "vite-plugin-graphql-codegen";

// https://vitejs.dev/config/
export default defineConfig({
  plugins: [react(), codegen({ configFilePathOverride: ".." })],
  resolve: {
    alias: {
      "@": path.resolve(__dirname, "./src"),
      // The following is needed to resolve an issue with the AWS SDK; https://stackoverflow.com/a/70939057
      "./runtimeConfig": "./runtimeConfig.browser",
    },
  }
});

Running npm run dev gives the following error:

failed to load config from /xxxxxx/vite.config.ts
error when starting dev server:
TypeError: codegen is not a function
    at file:///xxxxxx/vite.config.ts.timestamp-1660169078397.mjs:8:22
    at ModuleJob.run (node:internal/modules/esm/module_job:198:25)
    at async Promise.all (index 0)
    at async ESMLoader.import (node:internal/modules/esm/loader:385:24)
    at async loadConfigFromBundledFile (file:///xxxxxx/node_modules/vite/dist/node/chunks/dep-71eb12cb.js:62893:21)
    at async loadConfigFromFile (file:///xxxxxx/node_modules/vite/dist/node/chunks/dep-71eb12cb.js:62780:28)
    at async resolveConfig (file:///xxxxxx/node_modules/vite/dist/node/chunks/dep-71eb12cb.js:62398:28)
    at async createServer (file:///xxxxxx/node_modules/vite/dist/node/chunks/dep-71eb12cb.js:59018:20)
    at async CAC.<anonymous> (file:///xxxxxx/node_modules/vite/dist/node/cli.js:699:24)
arabold commented 2 years ago

Oh, the trick is to use codegen.default():

export default defineConfig({
  plugins: [react(), codegen.default({ configFilePathOverride: `${process.cwd()}/../codegen.yml` })],
  // ...

Now it seems to work for me.

danielwaltz commented 2 years ago

How strange, you shouldn't need to explicitly call the default export. Must be a bug. 🤔 I'll start looking into this and see if I can replicate. Thanks for the additional information!

sharmapukar217 commented 2 years ago

Solved

danielwaltz commented 2 years ago

Oh good, I take it the latest release fixed it then! I did a little housekeeping of the build and release process (and had some troubles with semantic release for a bit there 😬) hoping it would help.

andrew-w-ross commented 2 years ago

@danielwaltz This is still an issue, here is a reproduction https://github.com/andrew-w-ross/vite-plugin-graphql-codegen-default-issue. It's just the react-ts template from vite with the plugin added. I'm happy to make a pr to fix it if you want.

danielwaltz commented 2 years ago

Ok, I can confirm I'm seeing the issue in the reproduction repo. I'll start digging in here and see what I can find. 🤔

github-actions[bot] commented 2 years ago

:tada: This issue has been resolved in version 2.0.1 :tada:

The release is available on:

Your semantic-release bot :package::rocket:

danielwaltz commented 2 years ago

@andrew-w-ross I think I got it sorted! Related to default tsup (or maybe even esbuild) support being lacking for commonjs exports. Added a workaround for now until I can fully wrap my head around the problem and find a more reliable solution!

andrew-w-ross commented 2 years ago

@danielwaltz Thanks, I had a look at your fix and it confused me that tsup couldn't handle default exports. Turns out there is a bundle-formats option you have to set. I gave it a go on my fork and setting it did the trick without the options.footer change you did.

I created a pr #6, use it if you like but I just lightly tested it on the reproduction project. I tried it in both module and commonjs but that's the extent of my testing.

On a completely separate note, I didn't know about tsup it's excellent, really good find.