feat: configuration validation

[maschad]

Closes #1573
Closes #1757
Closes #1903

I decided to go with yup for a few reasons:

• Integration was more seamless
• Is used by substantially more projects ( 545k vs 105k)
• Preferred the schema building via chaining as opposed to defining complex functions (especially for defining integers, mins and defaults)
• Was more actively maintained ( most recent commit 3 weeks ago as opposed to last year November
• More downloads ( 4,201,246 vs 889,754 weekly downloads)

[maschad]

Currently blocked by #1867 unblocked

[achingbrain]

Looking good.

What's the thinking behind this pattern?:

class ServiceClass implements MyService {
  constructor (components, init) {
     // use init
  }
}

export function myService (init: MyServiceInit = {}): (components: MyComponents) => MyService {
  const validatedConfig = object({
    // config def
  }).validateSync(init)

  return (components) => {
    return new ServiceClass(components, validatedConfig)
  }
}

The thing that looks wonky to me is that the class doesn't validate it's args, it's done in the factory instead, so the class has to trust whatever it's given.

The config schema is also created for each object instantiation instead of having one definition that all instances can use - does it retain state or something?

Why not do something like:

const configSchema = object({
  // config def
})

class ServiceClass implements MyService {
  constructor (components, init) {
     init = configSchema.validate(init)
     // use init
  }
}

export function myService (init: MyServiceInit = {}): (components: MyComponents) => MyService {
  return (components) => {
    return new ServiceClass(components, init)
  }
}

[achingbrain]

See the comment above..

[maschad]

The thing that looks wonky to me is that the class doesn't validate it's args, it's done in the factory instead, so the class has to trust whatever it's given.

The config schema is also created for each object instantiation instead of having one definition that all instances can use - does it retain state or something?

If we continue to use factory method pattern with a 1-to-1 mapping of service to method then this way doesn't offer any benefits but also there isn't any drawback of the service object trusting the parameters it was passed (since only one method would pass those parameters in).

The config schema is also created for each object instantiation instead of having one definition that all instances can use - does it retain state or something?

Yup's schema is immutable, meaning that modifications to the schema will result in new schema instances rather than altering the original schema. So I can see the drawback of creating one for each object instantiated.

I don't have a strong opinion on doing it this way so if the memory savings outweigh the potential flexibility to have more factory methods then I can refactor.

I decided to refactor this given that we can also remove the need for re-setting the defaults in the constructor of the classes since yup returns an object with defined values for each field.

[maschad]

@achingbrain would you be able to give this a review please?

[SgtPooki]

I don't see any major errors but I have a few questions:

1. Are the changes in the *.spec.* files fixes to incorrect configs set during testing, that were found because of these changes? If so, that's great.
2. What is the bundle size increase with this?
3. Are there any hot-paths that we need to look out for?
   • things where instantiation happens frequently and config validation is re-run (and not needed)? If there are, I missed them.

[SgtPooki]

would love to see a link to the tests around the regex similar to https://www.regextester.com/104038 or https://regex101.com/r/aL7tV3/1 or similar

[maschad]

That link should suffice :) Normally I would agree with you but since it's for validation as opposed to a regex used in a function, the validation is a test in and of itself imo

[maschad]

I don't see any major errors but I have a few questions:

1. Are the changes in the *.spec.* files fixes to incorrect configs set during testing, that were found because of these changes? If so, that's great.

That's correct.

2. What is the bundle size increase with this?

Gzipped and minified yup is 12kB which is negligible

3. Are there any hot-paths that we need to look out for?

   • things where instantiation happens frequently and config validation is re-run (and not needed)? If there are, I missed them.

This would only instantiate one validation object per class that's already instantiated, which again is insignificant, any optimizations in that regard would be peripheral to this.

[achingbrain]

This was not ready. I know it's taken a long time but other issues have been higher priority. Please wait for review before merging.

[achingbrain]

The default value for these was fine before, why do these now need to be set?

[maschad]

See my comment #1778

[achingbrain]

Can we use a function for validation instead of a regex? Then reuse something like @chainsafe/is-ip

[maschad]

what's the benefit of using a external dependency and parsing the string over a regular expression?

[achingbrain]

Why do we need to specify the extra config now? This seems to happen in a few places here.

[maschad]

Because the intention is that we should not be able to have more inbound connections than maxConnections as that would result in them getting pruned anyways, discussing with @wemeetagain he raised a use case where this may be applicable though, where a node may want to reach maxConnections as fast as possible and so it may accept a greater amount of inbound connections in a short space of time.

[achingbrain]

I take it yup doesn't accept Infinity as a number?

[maschad]

Correct

[achingbrain]

Please have config definitions outside of the class so we don't create new validators on every object instantiation:

const configValidator = object({
  protocolPrefix: string().default(PROTOCOL_PREFIX),
  // ...etc
})

class DefaultAutoNATService implements Startable {
  // ...etc

  constructor (components: AutoNATComponents, init: AutoNATServiceInit) {
    const config = configValidator.validateSync(init)
    // ...etc
  }
}

[achingbrain]

Reverted and re-opened as #2133