Compile error with zod and mjs files

[han-tyumi]

I have initialized a clean Sanity repository with sanity-typed-schema-builder installed. I export the following:

// product.ts

import { s } from "sanity-typed-schema-builder";

export default s.document({
  name: "product",
  fields: [
    {
      name: "name",
      type: s.string(),
    },
  ],
});

and then import it:

// schema.js

// First, we must import the schema creator
import createSchema from "part:@sanity/base/schema-creator";

// Then import schema types from any plugins that might expose them
import schemaTypes from "all:part:@sanity/base/schema-type";

import product from "./product";

// Then we give our schema to the builder and provide the result to Sanity
export default createSchema({
  // We name our schema
  name: "default",
  // Then proceed to concatenate our document type
  // to the ones provided by any plugins that are installed
  types: schemaTypes.concat([
    /* Your types here! */
    product.schema(),
  ]),
});

When running sanity start, I run into:

$ sanity start
✔ Checking configuration files...
⠦ Compiling...webpack built e63f3d5408032c50286e in 5274ms
✔ Compiling...
Failed to compile.

Error in ./node_modules/zod/lib/index.mjs
Module parse failed: Unexpected token (330:8)
You may need an appropriate loader to handle this file type.
|     const fullPath = [...path, ...(issueData.path || [])];
|     const fullIssue = {
|         ...issueData,
|         path: fullPath,
|     };
 @ ./node_modules/sanity-typed-schema-builder/dist/types.js 35:12-26
 @ ./node_modules/sanity-typed-schema-builder/dist/builder.js
 @ ./node_modules/sanity-typed-schema-builder/dist/index.js
 @ ./schemas/product.ts
 @ ./schemas/schema.js (part:@sanity/base/schema)
 @ ./node_modules/@sanity/default-layout/lib/schemaErrors/SchemaErrorReporter.js
 @ ./node_modules/@sanity/default-layout/lib/defaultLayout/DefaultLayout.js
 @ ./node_modules/@sanity/default-layout/lib/defaultLayout/index.js
 @ ./node_modules/@sanity/default-layout/lib/Root.js (part:@sanity/base/root)
 @ ./node_modules/@sanity/base/lib/components/SanityRoot.js (part:@sanity/base/sanity-root)
 @ ./node_modules/@sanity/server/lib/browser/entry-dev.js
 @ multi ./node_modules/@sanity/server/lib/browser/entry-dev.js

Looks like a Webpack/Babel issue to me, but I'm not sure why I'd be seeing it if it's working for others. So I feel like I may be missing some configuration here? But I also don't see an easy way to modify the Sanity configuration, so 🤷‍♂️ .

[han-tyumi]

Looking through the "Used by" repos, I found this: https://github.com/HynekS/mulinem-nextjs-sanity/blob/main/cms/webpack.sanity.js.

This indeed fixes it for me. Looks like an undocumented Sanity feature. Do you use something like this as well @saiichihashimoto?

If so, maybe it should be documented in the README? Maybe even an example project?

[saiichihashimoto]

I do use something like that and I really dislike that it's required. If you can think of a proper solution, pull requests are definitely welcome (and encouraged!).

From what I understand, sanity v3 will handle mjs dependencies, so this might be a moot point going forward. It has been a pain point for everyone involved, though.

[saiichihashimoto]

It would be a breaking change, but I could treat zod like I do fakerjs, where it's not actually bundled with the package, but you'd bring your own zod:

const type = document(/* ... */);

- type.parse(somevalue);
+ type.parse(zod, somevalue); 

I honestly would prefer to go the other way, ie bundle fakerjs for mocks. Feels a lot like exposing implementation details. The only reason I'm ok with it for fakerjs is mainly because it's rarely needed for production.

[han-tyumi]

I'm personally just using it for the schema typings atm. I'm still very new to Sanity and am trying it out with a small side project. So making some of the other features 'opt-in' sounds good to me from my POV.

However, it seems like those features will become the main draw once v3 is released. I'd say just adding some docs on configuring Webpack until v3 seems like best option to me.

[trevorpfiz]

I was getting this error. I implemented the proposed fix above and it went away. Is it still required that I use the fix above or am I missing something? I don't believe I saw this in the docs, am I wrong?

[saiichihashimoto]

I haven’t added this to the docs yet, something I need to do.

[Waltari10]

My webpack.sanity.js looks like this:

const path = require("path");

const { isString } = require("lodash/fp");

const isBabelRule = rule =>
  Boolean(
    rule.use &&
      !isString(rule.use) &&
      "loader" in rule.use &&
      rule.use.loader?.includes("babel-loader")
  );

module.exports = ({ module: { rules = [], ...module } = {}, ...config }) => ({
  ...config,
  module: {
    ...module,
    rules: rules.flatMap(rule =>
      !isBabelRule(rule)
        ? [rule]
        : [
            rule,
            {
              ...rule,
              test: /\.mjs(\?|$)/,
              exclude: /bower_components/,
              include: [path.resolve(__dirname, "node_modules/zod/lib")],
            },
          ]
    ),
  },
});

And I'm getting this error:

$ sanity start
✔ Checking configuration files...
⠏ Compiling...webpack built 2d97ad2e8166f860dd77 in 15170ms
✔ Compiling...
Failed to compile.

Error in ./node_modules/@floating-ui/dom/dist/floating-ui.dom.esm.js
Module parse failed: Unexpected token (307:11)
You may need an appropriate loader to handle this file type.
|   }
| 
|   return { ...rect,
|     x: rect.x - scroll.scrollLeft + offsets.x,
|     y: rect.y - scroll.scrollTop + offsets.y
 @ ./node_modules/react-select/dist/react-select.esm.js 24:0-26
 @ ./node_modules/sanity-plugin-media/dist/components/SearchFacetTags/index.js
 @ ./node_modules/sanity-plugin-media/dist/components/SearchFacets/index.js
 @ ./node_modules/sanity-plugin-media/dist/components/Controls/index.js
 @ ./node_modules/sanity-plugin-media/dist/components/Browser/index.js
 @ ./node_modules/sanity-plugin-media/dist/app.js
 @ ./node_modules/sanity-plugin-media/dist/index.js
 @ ./node_modules/@sanity/vision/lib/VisionTool.js (all:part:@sanity/base/tool)
 @ ./node_modules/@sanity/default-layout/lib/util/getRegisteredTools.js
 @ ./node_modules/@sanity/default-layout/lib/router.js
 @ ./node_modules/@sanity/default-layout/lib/Root.js (part:@sanity/base/root)
 @ ./node_modules/@sanity/base/lib/components/SanityRoot.js (part:@sanity/base/sanity-root)
 @ ./node_modules/@sanity/server/lib/browser/entry-dev.js
 @ multi ./node_modules/@sanity/server/lib/browser/entry-dev.js

Any idea? 🤔

[saiichihashimoto]

Honestly, not really figuring this out. The weird thing is that installing zod directly in your project without this package doesn't seem to create this error (actually, can you confirm this?). I'm not really sure where this is coming from. I think there's something wrong about how we're including zod, but I can't figure it out.

[saiichihashimoto]

I think #171 might make this irrelevant, not sure.

[saiichihashimoto]

If anyone in this issue is using sanity v3, are you able to update to v2.0.0 of this library and see if you still have this issue? @han-tyumi @ElektrikSpark @Waltari10

[trevorpfiz]

Hey! So, I moved to Sanity v3 following this example nextjs-blog-cms-sanity-v3. I have not tried to implement this library yet on my rewrite because with all the bugs I have experienced so far between the Next.js 13 app directory and Sanity v3 upgrade, I have tried to keep things simple.

Will let you know if get around to implementing this library again.