mis-spelled extraIncludes should throw a warning

[jaustin]

I just typo'd extraIncludes to extraincludes.

This confused me a lot, until I realised I'd missed the capital 'I'. (My 'i's aren't good enough?)

For other errors in my module.json I get errors, like if I'm missing a license.

Could we have a warning for this, too please?

[autopulated]

This is a little tricky, because we want to maximise compatibility: this means that old versions of yotta should probably ignore module.json properties introduced in new versions, and we can't simply add a warning that "extraIncludes" is missing, because it's use is regarded as bad practise, not to be encouraged ;)

Possibly things are stable enough now that warning about unrecognised properties isn't a problem though?

[jaustin]

In this case, I think I'm looking for a warning not that extraIncludes is
missing, but that we have a field we are ignoring...

Perhaps coupling this with some knowledge of the expected yt version
would help, right?

If I have something made for yt x.y and it doesn't include a field that x.y
required, then we warn/error?

On 5 February 2016 at 04:10, James Crosby notifications@github.com wrote:

This is a little tricky, because we want to maximise compatibility: this
means that old versions of yotta should probably ignore module.json
properties introduced in new versions, and we can't simply add a warning
that "extraIncludes" is missing, because it's use is regarded as bad
practise, not to be encouraged ;)

Possibly things are stable enough now that warning about unrecognised
properties isn't a problem though?

—
Reply to this email directly or view it on GitHub
#697 (comment).

[autopulated]

👍 having a minimum required yotta version in module files is definitely a good idea.

Also warning about unknown properties is something we should do: this would be a simple change to the schema, but if we want to have them as a separate level of warning/error than other schema errors, then we'll need to do it differently.

[Mousius]

I guess one counter to this is that in the npm land you can have a lot of extra config in the package.json which isn't necessarily for npm. For example, we have eslintConfig as a property rather than an extra eslintrc file. Do you want to force a separate configuration file for that rather than collecting all config in one place for a given module?

Regardless, required version of Yotta seems helpful as you mutate it.

[autopulated]

The minimum yotta version can now be specified (#703 / #706) :)

Having other tools store config at the root of module.json seems a bit risky: a good reason to do it might be to experiment with extra tools which provide functionality that might become core to yotta in the future (possibly this is why it it's allowed in npm, I don't know), but otherwise it seems like it's like to cause confusion.

[Mousius]

I think npm just isn't very fussy about what you put in there, I don't think there's a plan to merge any of the things sharing package.json into the core of npm because the community takes more responsibility for writing the modules using that configuration. Using the same eslint example the guys at npm would have to pick one of X linters as the packaged one which I don't think they'd be keen to do as it'd harm the community around the other ones.

And thanks for the heads up on the minimum version, did not see that!