I've had this idea in the back of my mind for a while now, and I wanted to run it here to get your thoughts before spending time on a PR. What do you think of augmenting instanceOf to allow it to take a container key?

This would allow something like this:

// ...
import SomeModel from 'my-app/models/some-model';

export default Component.extend({
  propTypes: {
    prop: PropTypes.instanceOf(SomeModel)
  }
});

To become:

// ...

export default Component.extend({
  propTypes: {
    prop: PropTypes.instanceOf('model:some-model')
  }
});

This seems (to me) to align nicely with how most other things in Ember work against the resolver rather than using direct imports. I did a quick pass over the existing implementation and I believe this would be pretty simple to implement—if I opened a PR, would you be interested?

E.g. instead of

propTypes: {
    _name: PropTypes.string.isRequired
}

Logging the message "Missing required property _name"

I'd like the ability to do something like

propTypes: {
    _name: PropTypes.string.isRequired(`comp-foo requires a name: {{comp-foo '<name>'}}`
}

Logging the message "comp-foo requires a name: {{comp-foo '<name>'}}"

Upgrade to the version release due to the resolution of ciena-frost/ember-frost-test#38

Currently, if a property defined as a shape() is given an object that meets that shape, but has additional properties, it will error because of the existence of unknown keys. Sometimes, consumers may want to specify what they expect, but not be upset if the user provides additional properties that they will simply ignore. It would be nice if we could support this by maybe accepting a second options block in the shape() method, or a single, boolean second argument for the purpose of enabling additional properties to be accepted:

stuff: PropTypes.shape({
  foo: PropTypes.string,
  bar: PropTypes.string
},
{
  additionalProperties: true
})

or

stuff: PropTypes.shape({
  foo: PropTypes.string,
  bar: PropTypes.string
}, true)

This is due to the addition of __ characters to the beginning of key names and that fact that the addon/utils/validators/ember-component.js file checks the keys via key.indexOf('COMPONENT_CELL') === 0 and not key.indexOf('COMPONENT_CELL') > -1

We should be able to mark certain properties as private, complaining when the property is set by the consumer when initializing an instance. For example a consumer of Ember.Component should not be passing in isDestroyed or isDestroying. We should allow a component to do something like:

propTypes: {
  isDestroyed: PropTypes.bool({private: true}),
  isDestroying: PropTypes.bool({private: true})
}

• Tasks that have the text "(verified)" after them are ones that have either already been tested or are known to work. This does not mean that you should not still be cautious but you likely don't have to do as much research as you might initially be inclinded to.
• None of the tasks make a determination of whether a dependency should be a dependency or devDependency UNLESS otherwise stated. Even then it is prudent to confirm this indicator.
• All dependencies should float to ^ unless the directions in the tasks indicate otherwise. The following entries are known items that should REMAIN pinned:
  • ember-prism

NPM

• upgrade ember-cli-google-fonts to ^2.16.2 (verified)
• determine whether npm-install-security-check is needed. if so ^1.0.4 is latest
• pin ember-cli-htmlbars-inline-precompile to 0.3.12
• pin ember-get-config to 0.2.2 and make a dependency
• determine dependencies vs devDependencies
• ember install ember-frost-test (verified)
  • ember-cli-chai will be updated to 0.4.3 so may encounter issues
  • ember-cli-mocha will be updated to 0.14.4 so may encounter issues
• remove useLintTree from ember-cli-mocha configuration in ember-cli-build.js
• update ember-spread to ^4.0.0 (verified)
• install ember-cli-frost-blueprints@^4.0.1 (verified)

BOWER

• pin prism to 1.6.0

For more consistency with React's propTypes. https://facebook.github.io/react/docs/reusable-components.html#prop-validation

oneOf enforces that the property is one of the specified values.
oneOfType enforces that the property is one of the specified types.

The most recent attempt to update this addon was reverted, are you open to revisiting this? If so I'm happy to do the leg work, I just don't want to unless I know it's something you are open to. My main reason for this is to remove the babel 5 dep here so upstream consumers like ember-block-slots aren't relying on babel 5 either.

It would be great to have a propType check for attributes that expect an ember component.

Would be handy to be able to specify what an array is supposed to be made up of with arrayOf

• Add contributors gravatars with links to their Github profiles.
• Add link to Github repository.
• Add license information.
• Add brief description of project at top of demo.
• Add proper syntax highlighting for code snippets.

Add a way to flag properties as being updatable. We can then wire into didUpdateAttrs() to make sure that only properties flagged for updates are being updated.

Currently validation runs in any non-production environment but we should make this configurable in config/environment.js like so:

'ember-prop-types': {
  disableValidation: true
}

I can't seem to find a public repository for npm-install-security-check, but its introduction in ember-prop-types is where we came across it, and it looks like @sandersky is tied to both packages.

It seems npm 2 doesn't provide strong enough ordering guarantees for what npm-install-security-check wants to accomplish. Given the package.json below, a fresh npm install will fail because cli-color's dependencies aren't yet all available when npm-install-security-check's postinstall hook executes. This is causing build failures for us in CI.

{
  "name": "install-failure",
  "private": true,
  "dependencies": {
    "cli-color": "^1.1.0",
    "npm-install-security-check": "^1.0.2"
  }
}

Errors aside, this also seems like an odd judgment for an addon to be making on behalf of its consumers. I understand that the security vulnerability involved is pretty scary, but it seems like having a random smattering of dependencies issue loud warnings may not be the best way to raise awareness.

As npm points out in the blog post announcing the vulnerability, there are real-world use cases that require install scripts. Legitimate packages like phantomjs-prebuilt will silently fail to fully install if the advice in npm-install-security-check's warning message is followed blindly.

On balance, it’s npm’s belief that the utility of having installation scripts is greater than the risk of worms. This is a tradeoff that we will continue to evaluate.

Given the tradeoffs, it seems like users should be able to make their own informed decision about this. Currently, however, if a user reaches a different decision than any library author who's decided to include npm-install-security-check as a dependency, it means they're subjected to loud warnings any time they install, with no way to opt out.

I have a propType that expects a string. However, passing a SafeString object (the result of calling Ember.String.htmlSafe() on a string) is not validated as being a string. I think that the string validation should allow SafeString objects.

Which is the correct location, however when attempt to do so it does not work.

loader.js:219 Uncaught Error: Could not find module dummy/config/environment imported from ember-get-config/index

I've started seeing this error after updating bower/npm. Seems like some upgrade spoiled the party

when run ember serve

Hello,

I have a date-picker component which expects date object as a parameter. Based on ember-prop-types docs I can use only object value. But when I use it, I've got an error that provided parameter (date) is not an object. In object validator I've noticed that you use Ember's typeOf method (https://www.emberjs.com/api/#method_typeOf) which returns date not an object.
Right now I switched to any but maybe you should consider defining also date (and other values like regexp) in propTypes ?

PR #129 introduced SafeString support. At the time the PR was submitted and the builds ran, the ember-try scenarios and travis.yml configuration did not contain a build for Ember v2.4. Subsequent to the PR being opened such a scenario was added to master which this PR did not have the changes for prior to its merging.

The code introduced in #129 is not compatible with Ember v2.4 (https://travis-ci.org/ciena-blueplanet/ember-prop-types/builds/260170139). This means that every run of tests from this point forward will fail. It also means that anyone using Ember v2.4 that requires a String PropType and passes something that is not a string will fail as well.

I recently made a PR to ember-block-slots that was merged. Unfortunately, in the meantime, its dependency on this library and the recent version bump to v2.1 has broken the app that uses ember-block-slots.

I'm getting the following error in my app:

loader.js:218 Uncaught Error: Could not find module lodash imported from ember-prop-types/mixins/prop-types

I can't really wrap my head around whether this is an issue with v2.1.0 itself, or whether ember-block-slots package.json is too loose with its dependency version on this library.

Locking in my app's ember-prop-types version to v2.0.1 fixes this issue.

Happy to provide more context if it would be helpful.

Get implementation code from here.

I think this would be super helpful when introducing new devs to a code base.
How hard would it be to add? (if it doesn't already exist)

As per suggested by @sandersky, I'm opening this issue as a discussion surrounding the opportunity to make this library more light-weight by removing the lodash dependency.

A cursory check looks like most of the usages are type checks, which I think ES6/babel provides a lot of already.

Any thoughts?

It may be helpful to log warnings/errors when an unexpected property is passed into a component. For example, if a component takes a property called value and someone provides valu or bunsenValue it would be nice to warn them they may have an error in their template.

FIrst off, I love this addon. This brings a great pattern from the React world to Ember and I really hope more people continue to adopt it!

As a result of wanting to use it all the time, I started to wonder if the prop types make it into the production build when Ember compiles everything? I definitely want to add prop types to everything during development, but I'm hesitant to do so if it means all of that is going to get transpiled into the production bundle.

Would it be possible to strip out all the prop types when doing ember build -prod? Similar to this react optimization: https://github.com/oliviertassinari/babel-plugin-transform-react-remove-prop-types

I'd be happy to work on a PR for this if you think it's doable and can point me in the right direction.

It was added in #140

Just thought it'd be a good idea, so you can write tests that assert an error was thrown. :)

BUG REPORT

• I have ensured that the issue isn't already reported
• I have confirmed that the issue is reproducible with the latest released version
• I have deleted the FEATURE REQUEST / CODE CHANGE section

Summary

• A warning is logged to the browser console
• Warning message is Expected property data to be an array but instead got: instance
• Possibly related to issue #117

Expected Behavior

• A warning should not be logged to the browser console

Actual Behavior

• What happens instead of the expected behavior?
• Is something broken, or not behaving as you expected?
• Attach a screenshot or recording as appropriate.

Possible Solution

• Address issue #117, which I think is related

Steps to Reproduce

• Include the contents of your package.json file
• Steps to reproduce:
  1. Use PropType.array to define a property
  2. Pass in an instance of an array as that property
  3. View browser console for the warning

Context

• This issue has produced many warnings in the browser console

Environment

(answer all that are applicable)

• I am using the latest released version (can check with npm ls <package-name>)
• I am using these browsers:
  • Latest Chrome
  • Latest Firefox
• My version of Node is: 8.6.0
• My version of npm is: 5.3.0
• My OS is:
• Include the contents of your package.json file

I have a component foo, and a mixin foo-common that adds a common API to that component. Both use ember-prop-types.

The component foo has a propTypes attribute and a getDefaultProps() method. So does the mixin foo-common.

There are two problems with the result:

1. The propTypes for the foo-common are not set, because ember-prop-types does not define propTypes as a concatenatedProperty. The propTypes for foo override those in foo-common.
2. The default property values for the mixin are not set, because getDefaultProps from foo similarly overrides foo-common.

PR pending.

Currently, there are not Ember javascript module declarations for:

const {Logger} = Ember

or

const {VERSION} = Ember

Stems from this call https://github.com/ciena-blueplanet/ember-prop-types/blob/master/addon/utils/validators/index.js#L37

Which is weird since Ember assign was introduced in September and I’m using ~2.5.0 so I should have it.

Reproducible in https://github.com/EWhite613/ember-frost-list/tree/list-item-redesign

I am running into an issue where one of my required propTypes is undefined. I would expect isRequired to prevent allowing undefined.

propTypes: {
  myProp: PropTypes.any.isRequired
},

myComputedProp: computed('myProp', function() {
  let myProp = this.get('myProp'); // undefined!
})

I assume this message means that some required property was not specified somewhere. But where? The message doesn't tell me. I can put a breakpoint where the message is logged but the huge call stack (100s of levels) doesn't make things easy. Please make the message more useful by giving me some sort of path to the component that is missing the required property.

I believe there is an unsafe assumption on this line because .toString() on an object doesn't always have the string function() in it.

A simple example is an array:

[1,2].toString()
"1,2"

in a scenario like this, you'll get the following error on the above referenced line: Cannot read property '1' of null