tamj0rd2 / ncdc Goto Github PK

vega/ts-json-schema-generator#101 (comment)

It doesn't need to be renamed completely. But for consistency's sake, it makes sense to have --schemaPath be the default option name. outputPath can be an alias.

All variations need to be checked

Needs test in schema.integration.spec.ts

If fetching fails, the message that gets printed it something like: expected status code but got 0.

This is weird. It should just say there was some kind of connection failure

It spits out way too much information sometimes. It'd be really cool to cut it down to the barebones. Just enough to help troubleshoot what's going wrong.

If someone serves a body that they expect to be of type number, all is well in the world.
But what if someone tests an API with that same config? What we get back from the API will most likely be a string. Is this supposed to try to parse that to a number, or whatever other type they want it to be to check the validity?

• Generate
• Test

This way, ncdc serve can restart if any types change.

Otherwise people may experience behaviour where they change their types to be incorrect and but their server keeps running perfectly fine with no feedback.

e.g, config.request.endpoints is not allowed

error: type not found

It should at least say the config name or something

• logic to get this feature working fully needs to be amended

request.bodyPath (pending changes)

• Description: A path to the body you expect to make requests to the endpoint
  with. It must be a JSON file (should be updated to support other files in the
  future). Cannot be specified at the same time as request.body. Relative
  paths should be relative to the config file's location

  In Serve mode, if this property is specified without request.type, responses
  will only be served if the request body matches request.body

• Type: string

• Required?: No

• Example: bodyPath: ./my-response.json or bodyPath: /some/absolute/path

Manual testing sucks. I need to think of a good way to move that work into integration and/or acceptance tests

Currently it says this:

error: Could not restart ncdc server: Unexpected end of JSON input

It'd help if it mentioned the filename that has the problem

There has to be some better way to deal with query strings

For example: /api/v1/resource?greetings=hello&greetings=yo

I probably want the response for that address to be available no matter what order those query params come in.

It makes my eyes bleed

• Rewrite the config using Joi #46
• Only create a type validator if necessary #49

• In Test Mode, call the endpoint with the headers
• In Serve Mode, make sure the headers are present, otherwise respond with a 404

• Make this work as described in serve mode
• Make this work as described in test mode

Getting this error when trying to run serve on the latest version

JSON files can already be loaded, but only json.

• Add yaml support
• Support other extensions as just text

Atm in test mode, the type validator gets created regardless of whether or not any configs contain Types. Hopefully the config re-write for test mode will fix this, but tracking here just in case.

• Server mode
• Test mode

https://github.com/tamj0rd2/ncdc/blob/master/src/config/body.ts

And all that config stuff is generally awful

microsoft/TypeScript#30661 (comment)

When there's support for noEmit + incremental, that will speed this up so much

• Update docs with usage suggestions for local development
• Make the link to the Config documentation more clear
• Update the example in the main readme to show 2 different configs

Make sure the type actually works like this and gives back a useful error message

• Serve mode
• Test mode

• Add support for other HTTP methods

• Does the 405 and allow header thing actually work?

• Description: The HTTP method you would call the endpoint/s with. Currently,
  only GET and POST are supported
  
  In Serve mode, if the endpoint exists but is called with the wrong method, it
  will return a 405 response with an Allow header.

• Type: string

• Required?: Yes

• Example:

  method: GET

To reproduce

1. Start the server
2. Change config.yml
3. the server restarts and is available
4. Change config.yml again
5. nothing happens

Context:

export interface RequestConfig {
  method: SupportedMethod
  endpoint: string
  // TODO: in serve move, only check either Type or Body. not both
  body?: Data
  type?: string
  headers?: IncomingHttpHeaders
}

• Needs a sanity check

request.serveEndpoint (pending changes)

• Description: An endpoint to serve the corresponding response. This
  supports ExpressJS string patterns
  (read more).
  Regex is not yet supported.
  
  This property is ignored in Test mode and overrides
  request.endpoints when in Serve mode.
• Type: string
• Required?: Required in Serve mode if request.endpoints is not provided
• Example:

  serveEndpoint: /api/books/*

Right now, the http client will try to parse the response as JSON if the user has configured a response content-type of application/json

Really, it should base it on the request's accept header

• Restart serving when the yaml file changes
• Restart serving when a file containing mock json changes
• Add acceptance test cases to make sure the type stuff works properly

if (responseConfig.body !== undefined && response.data !== responseConfig.body) {

If response.data and responseConfig.body are both objects, this won't work.

Dependabot encountered the following error when parsing your .dependabot/config.yml:

Automerging is not enabled for this account. You can enable it from the [account settings](https://app.dependabot.com/accounts/tamj0rd2/settings) screen in your Dependabot dashboard.

Please update the config file to conform with Dependabot's specification using our docs and online validator.

Obviously this should only use for the serveEndpoint value.

A wildcard * is probably a good character option. e.g

serveEndpoint: /api/resource?thingy=*

I feel like that should allow thingy to be any value or an array containing any values

• Add a basic test mode acceptance test first

It's much nicer to use and will help to fix some bugs that are floating around

Like source files/acceptance tests etc

It used to spit out quite a lot. Not sure what the state of it is nowadays.

It'd be great to finally have some of these.

Could create a basic express server that serves up some hardcoded responses and test using that. Then spy on console.log or winston or whatever to find out what the output was.

• In serve mode, respond with these headers
• In test mode, check that these headers are received

response.headers (pending changes)

• Description: The headers you expect to receive from the endpoint. Header
  names are case insensitive
• Type: object
• Required?: No
• Example:

  headers:
    content-type: application/json
    Cache-Control: no-cache

Output:

Response <root> should be object
Data: <some stringified object>

For some reason the data is not being parsed as an object

Similar to this issue, but not quite the same: #101

• Sanity check for Serve
• Sanity check for test

request.endpoints (pending changes)

• Description: A single endpoint or list of endpoints that you'd like to
  test or serve.
  

  In Serve mode, if your configured endpoints contain a query string, responses
  will only be served if your request has matching query params. For example, in
  order to get responses for the configuration endpoints: /endpoint?size=5&size=6,
  you would need to make a request that include size=5 and size=6 as query
  params. If you leave either of them out of the request, your response will not
  be served and you'll receive a 400 status code. Providing extra params does not
  cause adverse effects.

• Type: string or string[]

• Required?: Required in Test mode if serveOnly is false

• Example:

  endpoints: /my/endpoint
  # Or...
  endpoints:
    - /my/endpoint1
    - /my/endpoint2?hello=world # only served if request has query param "hello" with value "world"

Currently it's this: Could not build a generator from the given typescript configuration

Which is a bit cryptic

This is possibly misleading. What does it actually do when string/number/boolean is given? HTTP responses are strings anyway. This should probably only allow string, object or a complex type.

• Add [] syntax to expect an array of a certain type

response.type

• Description: The name of a typescript symbol or a JSON schema file
  (excluding the .json). In Test mode, validation will be done between the actual
  response and the type. The test will fail if the body does not match the schema.
  In Serve mode, if body, bodyPath, serveBody or serveBodyPath are
  specified, validation will be done between the type and the mock response. If
  validation fails, you will receive an error and the mocks will not be served.
• Type: string
• Required?: No
• Example: type: SomeInterfaceName