How to display source file for conflicting fields types?

[henricazottes]

Hi,
When building my site containing a lot of .md files full of frontmatter, I get warnings about conflicting field types. This is a valuable information, but it's missing one thing: which files are conflicting.

I've seen this conversation here where you can see screenshots with the path to the source file.

But for me source is not showing up.

MarkdownRemark.frontmatter.mepheader.provenance.prov_number:
 - type: object
   value: { anote: [Object] }
 - type: string
   value: 'p. 264'
MarkdownRemark.frontmatter.head:
 - type: object
   value: { dateline: 'sans date', persname: [Object], object: 'Dessin de M. Isabey de la manufacture des frères Sevennes à Rouen.' }
 - type: string
   value: '[1133]'

Digging a little where the message is actually prompted, I've found that the source line is displayed only if the node has a description:

type-conflict-reporter.js

    report.log(
      `${this.selector}:${sortedByTypeName
        .map(
          ([typeName, { value, description }]) =>
            `\n - type: ${typeName}\n   value: ${formatValue(
              value
            )}${description && `\n   source: ${description}`}` // <-- Here
        )
        .join(``)}`
    )

I've quickly looked around but didn't find what is this description. On the node interface documentation page no sign of it.

I think adding this description is not the way to go, but I'm missing leads.

Any suggestion how to proceed?

[vladar]

Hi @henricazottes !

Thanks for this question. This sounds like a reasonable thing to have. The PR you linked is for Gatsby v1. But I did some digging and looks like we stopped displaying the source after #16091.

There is actually this comment: https://github.com/gatsbyjs/gatsby/pull/16091/files#r316047900 which hints that it is probably possible to restore this behavior.

@freiksenet Do you remember why it was removed in the first place?

Given what I see gatsby-source-filesystem still sets the description (here) so the scope of the change seems to be relatively narrow.

We'll be happy to accept a PR for this change 💜 Feel free to ping me for any help or advice if you decide to tackle it!

[henricazottes]

Interesting!

On my part I've found that prepareConfilctExample never returns any parent:

    return {
      type: typeNameMapper(type),
      value: reportedValueMapper(type),
    }

And as the description is found in the parent (see addExample):

  addExample({
    value,
    type,
    parent
  }) {
    this.types.set(type, {
      value,
      description: findNodeDescription(parent)
    });
  }

I guess it explains why it's not displayed.

However we do have access to first in the descriptor given to buildExampleValue, which looks like a nodeId:

// descriptor
{
  "string": {
    "total": 1103,
    "first": "31b3aa77-7e13-5954-82b7-6661162f20d6",
    "example": "sans date",
    "empty": 2,
  }
}

With that and the node api helper it should be pretty easy to access the parent (if this nodeId looking stuff is the parent Id). But as I don't have the big picture of that block I don't know where is the best place to inject/retrieve it.

@vladar if you give me some directions it would be a pleasure to make a PR :)

[davidbelow]

If @freiksenet gives a good reason why it was removed it would mean that this behavior cannot be restored easily?

[henricazottes]

You're right, I'll wait for his answer before investigating more

[vladar]

@henricazottes You are right about first - it is a node id that you can use to find a root ancestor node. I guess the best advice I can give is to try to restore this line

The implementation of this function still exists here but it is not easily accessible from type conflict reporter anymore. I suspect it was the main reason for the change.

So you will probably have to re-implement it using node store directly. I would suggest putting this new implementation in the utils folder for now as a standalone utility function.

[github-actions]

Hiya!

This issue has gone quiet. Spooky quiet. 👻

We get a lot of issues, so we currently close issues after 30 days of inactivity. It’s been at least 20 days since the last update here.
If we missed this issue or if you want to keep it open, please reply here. You can also add the label "not stale" to keep this issue open!
As a friendly reminder: the best way to see this issue, or any other, fixed is to open a Pull Request. Check out gatsby.dev/contribute for more information about opening PRs, triaging issues, and contributing!

Thanks for being a part of the Gatsby community! 💪💜

[github-actions]

Hey again!

It’s been 30 days since anything happened on this issue, so our friendly neighborhood robot (that’s me!) is going to close it.
Please keep in mind that I’m only a robot, so if I’ve closed this issue in error, I’m HUMAN_EMOTION_SORRY. Please feel free to reopen this issue or create a new one if you need anything else.
As a friendly reminder: the best way to see this issue, or any other, fixed is to open a Pull Request. Check out gatsby.dev/contribute for more information about opening PRs, triaging issues, and contributing!

Thanks again for being part of the Gatsby community! 💪💜