I'm using it to do validating. Currently PropTypes.checkPropTypes will not throw or return false or return rejected promise on checking failed, and this makes me hard to know if checking was failed so I write a function to do checking manually..

function customedCheckPropTypes(typeSpecs, values, location, componentName) {
  const promiseArray = Object.keys(typeSpecs).map((typeSpecName) => {
    if (typeof typeSpecs[typeSpecName] !== 'function') return Promise.reject(`${location}, ${typeSpecName}: TypeChecker should be a function`);
    const error = typeSpecs[typeSpecName](values, typeSpecName, componentName, location, null, 'SECRET_DO_NOT_PASS_THIS_OR_YOU_WILL_BE_FIRED');
    // specified using prop-types version 15.5.8 only in package.json
    if (error instanceof Error) return Promise.reject(`Failed ${location} type: ${error.message}`);
    return Promise.resolve();
  });
  return Promise.all(promiseArray);
}

Maybe checkPropTypes return false on failed can help a lot.

@reallyimeric This works, but only if you don't set NODE_ENV=production, otherwise you'll get shims in place of typeSpecs.

any updates ?

For anyone looking for a validating library, ajv would be a good choice.

I want to use like this:

class Test {
  constructor(props) {
    this.scale = props.scale;
  }
}

Test.propTypes = {
  scale: PropTypes.number,
};
Test.defaultProps = {
  scale: 1,
};

const test = new Test({});

// expect: 1
console.log(test.scale);

🤧🤧🤧

@dragonwong for that to work, the JS language itself would have to support prop types and default props. You can, however, do this:

class Test {
  constructor({ scale = 1, ...rest }) {
    this.props = { scale, ...rest };
  }
}

@ljharb thanks, but I think it can not support complex feature such as PropTypes.shape, PropTypes.oneOfType, .isRequired and etc. 😰

And prop-types can check the props, when the props is invalid it will throw a warning, I think that is really important too.

aggree with @dragonwong , I was trying to use prop-types in nodeJS for attributes validation

I'm not sure what's still actionable here - you can certainly use this library outside React (checkPropTypes), but the language doesn't have the ability to do it for you. Closing, but happy to reopen if needed.

@ljharb The use case example given in the original issue can't be done with the library, as-is. You can, indeed, call checkPropTypes to check if a JSON object matches a props description (although you need to pass in some names that really have nothing to do with checking if a JSON object matches a schema), but, from the documentation:

If you absolutely need to trigger the validation manually, call PropTypes.checkPropTypes(). Unlike the validators themselves, this function is safe to call in production, as it will be replaced by an empty function

Emphasis mine. So in my example where I'm trying to prevent someone from passing bad data via a REST API, I can verify that with prop-types on the server, but it will automatically be turned off for me in production. This is not desired behavior for a schema checking library.

@jwalton ah - you can choose to use the development version in production, and it'll work fine https://unpkg.com/prop-types@15.7.2/prop-types.js

But how would I do that? NODE_ENV is set to 'production' on my production servers, because all the other node packages I use rely on it being set that way to behave sensibly in production. I'd have to do something hacky like:

const originNodeEnv = process.env.NODE_ENV;
process.env.NODE_ENV = 'development';
const propTypes = require('prop-types');
process.env.NODE_ENV = originNodeEnv;

Yuck.

The file I linked does not check process.env; it's hardcoded to development.

iow, instead of requiring prop-types, you can use prop-types/prop-types in your bundler.

If you open up node, and try:

p = require('prop-types/prop-types');
console.log(p.checkPropTypes.toString());

You'll see the code is:

function checkPropTypes(typeSpecs, values, location, componentName, getStack) {
  if ("development" !== 'production') {
    // Do a bunch of stuff
  }
}

Open up that link you posted above and find checkPropTypes and you'll see it's the same.

Yep, and that works fine, because the string "development" will never be equal to the string "production".

I am not a smart man. :P Thanks, sir.

@jwalton ah - you can choose to use the development version in production, and it'll work fine https://unpkg.com/prop-types@15.7.2/prop-types.js

I'd like to see this in the docs, that would be a big help :)

a PR is welcome.

@ljharb #262

import * as PropTypes from 'prop-types/prop-types'
This doesn't work for TypeScript because internal prop-types.js file is untyped.

@alexeychikk then that’s a bug in the DT package - all files should be typed, not just the main. (separately, import * there is incorrect; TS’ module system is broken unless you enable synthetic imports and es module interop)

@ljharb TS module system is not the issue. With esModuleInterop it works both ways:

import * as PropTypes from "prop-types";
import PropTypes from "prop-types";

The problem is that type definitions in @types/prop-types are not defined for prop-types/prop-types.js.

Sure, that's why i said "separately" :-) please file a bug on DT so that the types can be defined for every file.