Failed prop type: Invalid prop remarkPlugins[2] supplied to ReactMarkdown

[starpit]

After upgrading to react-markdown 8.0.0, we get this console error:

Failed prop type: Invalid prop `remarkPlugins[2]` supplied to `ReactMarkdown`, expected one of type [object, function].

When using e.g. this as out remarkPlugins:

import frontmatter from 'remark-frontmatter'
...
   remarkPlugins: [[frontmatter, ['yaml', 'toml']]

Using

• remark-frontmatter@4.0.1
• react-markdown@8.0.0
• react@17.0.2
• typescript@4.5.5

[ChristianMurphy]

This is something that could be improved, currently the prop types expect a function or an object. https://github.com/remarkjs/react-markdown/blob/cd845c9f38e0280b67fa33cc8e1fcf9d2cd0cc72/lib/react-markdown.js#L140-L152
Array of string currently isn't included, but probably could be.
PR(s) are welcome!

[starpit]

There are I think several issues here:

1. what is really desired is that the first argument is always a function. The rest of the arguments can be... anything, right? That is, I am allowed to pass whatever options to my plugin that I want... of any type. It's just that the first element of the array has to be a function.

2. The prop-types module does not seem to support this kind of "tuple" semantics. I.e. the array isn't really an array, but a tuple (handlerFn, opt1, opt2, opt3). The airbnb-prop-types module has a sequence construct that might help, not sure.

3. Furthermore, if you try to shoe-horn this into prop-types, e.g.

remarkPlugins: PropTypes.arrayOf(                                                                                   
    PropTypes.oneOfType([                                                                                             
      PropTypes.string,
      PropTypes.object,                                                                                               
      PropTypes.func,                                                                                                 
      PropTypes.arrayOf(PropTypes.oneOfType([PropTypes.string, PropTypes.object, PropTypes.func]))                                      
    ])                                                                                                                
  )

Then it just gets horribly confused. It simply does not seem to support a case like this:

[frontmatter, ['yaml', 'toml']]

It still complains:

Invalid prop remarkPlugins[3] supplied to ReactMarkdown, expected one of type [string, object, function].

Which makes no sense to me, since the "expected one of" message does not include the arrayOf... So either there are bugs in prop-types, or... we want to use it for something for which it is not designed.

[starpit]

Something like...

  remarkPlugins: PropTypes.arrayOf(                                                                                   
    PropTypes.oneOfType([(plugins, idx, ignore1, ignore2, name) => {                                                  
      const _ = plugins[idx]                                                                                          
      if (!(typeof _ === 'function' || typeof _ === 'object' || Array.isArray(_))) {                                  
        return new Error(`${name} must be either a function, object, or array: ${_}`)                                 
      } else if (Array.isArray(_) && typeof _[0] !== 'function') {                                                    
        return new Error(`${name}[0] must be a function: ${_[0]}`)                                                    
      }                                                                                                               
    }])                                                                                                               
  ),   

[starpit]

And then I don't know how to get sufficient test coverage of the failing cases, when your tests also have a parallel set of typescript checks. Either the code won't type check, or it will fail test coverage for the prop types logic...

[ChristianMurphy]

what is really desired is that the first argument is always a function. The rest of the arguments can be... anything, right? That is, I am allowed to pass whatever options to my plugin that I want... of any type. It's just that the first element of the array has to be a function.

No
For the first parameter is can be any pluggable type, which includes preset objects and attacher functions.

How the rest of the elements are handled depends on whether we're talking about runtime types or static types.

• From a static typing perspective, the values of a preset/attaches options are known ahead of time and should exactly match
• From a runtime perspective, the exact values may not be known, but we do know the most common things passed through, and those are currently listed, we may add to the list, but I don't see any as being a good fit

The prop-types module does not seem to support this kind of "tuple" semantics.

it currently does not

The airbnb-prop-types module has a sequence construct that might help, not sure.

It may be worth looking into.
I'm a bit cautious adding too much complexity to the prop types, right now the TypeScript types offer a more precise understanding of what is accepted.
The prop-types more ensure it looks about right for non-ts users, but we don't have enough detail at runtime to exactly match.

So either there are bugs in prop-types, or... we want to use it for something for which it is not designed.

It seems like something worth asking the prop-types maintainers

I don't know how to get sufficient test coverage of the failing cases, when your tests also have a parallel set of typescript checks.

I'm not sure I follow?
Test coverage and type coverage are independent.
Type coverage doesn't prevent writing test cases, and test cases doesn't prevent ensuring type coverage.
Unified projects aim for 100% coverage on both tests and types, and has for all projects including this one.

If you have specific questions on how to write TypeScript or how to write tests, folks may be able to help.

Taking a step back for a moment, writing a custom validator may not be needed, what you're trying to do probably is (or should be) supported by prop-types in some way, without writing a custom validator.

[starpit]

Thanks. Probably my not quite understanding prop-types fully. See Shttps://github.com/remarkjs/react-markdown/pull/683