tamj0rd2 / ncdc Goto Github PK
View Code? Open in Web Editor NEWA CLI that takes a consumer driven contract defined in yaml and allows you to run tests and/or create a fake server
License: MIT License
A CLI that takes a consumer driven contract defined in yaml and allows you to run tests and/or create a fake server
License: MIT License
Getting this error when trying to run serve on the latest version
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.
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.
Make sure the type actually works like this and gives back a useful error message
error: type not found
It should at least say the config name or something
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.
Currently it's this: Could not build a generator from the given typescript configuration
Which is a bit cryptic
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
It's much nicer to use and will help to fix some bugs that are floating around
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
}
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.
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
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
e.g, config.request.endpoints is not allowed
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
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
To reproduce
JSON files can already be loaded, but only json.
Manual testing sucks. I need to think of a good way to move that work into integration and/or acceptance tests
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.
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
All variations need to be checked
Needs test in schema.integration.spec.ts
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.
Like source files/acceptance tests etc
microsoft/TypeScript#30661 (comment)
When there's support for noEmit + incremental, that will speed this up so much
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?
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"
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 used to spit out quite a lot. Not sure what the state of it is nowadays.
if (responseConfig.body !== undefined && response.data !== responseConfig.body) {
If response.data and responseConfig.body are both objects, this won't work.
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
headers:
content-type: application/json
Cache-Control: no-cache
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.
body
, bodyPath
, serveBody
or serveBodyPath
aretype: SomeInterfaceName
request.endpoints
when in Serve mode.request.endpoints
is not providedserveEndpoint: /api/books/*
https://github.com/tamj0rd2/ncdc/blob/master/src/config/body.ts
And all that config stuff is generally awful
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.