@types/hapi__joi needs to be a prod dependency

[bowernite]

Since the index.d.ts file relies on importing the types derived from @types/hapi__joi, and since packages consuming express-validation needs their TS to compile, this needs to be a dependency instead of a devDependency.

Otherwise, consumers using TypeScript will get the following error:

node_modules/express-validation/lib/index.d.ts:8:8 - error TS7016: Could not find a declaration file for module '@hapi/joi'. '/Users/abr1402/nml/ms-pep/node_modules/@hapi/joi/lib/index.js' implicitly has an 'any' type.
  Try `npm install @types/hapi__joi` if it exists or add a new declaration (.d.ts) file containing `declare module '@hapi/joi';`

} from '@hapi/joi';

[AndrewKeig]

@babramczyk, thanks for the issue, can I get a pr, would really appreciate this, typescript is not my thing, and I would ideally like someone who does use it to test it..

It also states 'or add a new declaration (.d.ts) file', can we do that instead?

[bowernite]

@babramczyk, thanks for the issue, can I get a pr, would really appreciate this, typescript is not my thing, and I would ideally like someone who does use it to test it..

Sure thing. Should be a super simple fix.

If you're not familiar with what's going on -- basically, since @types/hapi__joi is a devDependency, when consumers of your package npm i express-validation, @types/hapi__joi will not be installed anywhere in their node_modules.

However, they will get your lib/index.d.ts, for which their TypeScript compiler will use for checking types for your project. Since your lib/index.d.ts imports and relies upon types from the @types/hapi__joi project, the error I posted above will occur since that devDependency was never installed.

It also states 'or add a new declaration (.d.ts) file', can we do that instead?

This is referring to the consumer making a .d.ts file on their own to make up for missing types. In this scenario, that would look something like this:

@declare module @hapi/joi {
  ValidationOptions: ...
  ValidationError: ...
  Root: ...
}

[bowernite]

@AndrewKeig opened #109

[AndrewKeig]

hey @babramczyk , before i merge this, can i ask one more thing, would you mind adding a typescript example to the readme, we have this example in javascript, could you typescriptify it :). and stick it in the readme, with any notes. thanks.

const express = require('express')
const bodyParser = require('body-parser')
const { validate, ValidationError, Joi } = require('express-validation')

const loginValidation = {
  body: Joi.object({
    email: Joi.string()
      .email()
      .required(),
    password: Joi.string()
      .regex(/[a-zA-Z0-9]{3,30}/)
      .required(),
  }),
}

const app = express();
app.use(bodyParser.json())

app.post('/login', validate(loginValidation, {}, {}), (req, res) => {
  res.json(200)
})

app.use(function(err, req, res, next) {
  if (err instanceof ValidationError) {
    return res.status(err.statusCode).json(err)
  }

  return res.status(500).json(err)
})

app.listen(3000)

[bowernite]

So with that example, there's really no "typescriptifying" to be done

With TypeScript, a lot of its compile-time checking will happen regardless of if you use type annotations or not.

The only way to really communicate that this package "works" with TypeScript would be to modify your JS example to be an incorrect usage of the package, demonstrating that TypeScript would error; I'm not sure this is really helpful.

tl;dr: TypeScript users don't need to do anything to use your package in a "TypeScript way", so your README doesn't need to add anything for it 🙂

[AndrewKeig]

:), cheers dude.