Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat(server): check that serverMode implementation is correct #2051

Open
wants to merge 4 commits into
base: master
Choose a base branch
from

Conversation

knagaitsev
Copy link
Collaborator

  • This is a bugfix
  • This is a feature
  • This is a code refactor
  • This is a test update
  • This is a docs update
  • This is a metadata update

For Bugs and Features; did you add new tests?

Yes

Motivation / Use-Case

This feature gives useful error messages when the user provides an incorrect serverMode implementation.

Breaking Changes

None

Additional Info

@codecov
Copy link

codecov bot commented Jun 20, 2019

Codecov Report

Merging #2051 into master will increase coverage by 0.04%.
The diff coverage is 100%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master    #2051      +/-   ##
==========================================
+ Coverage   92.77%   92.82%   +0.04%     
==========================================
  Files          29       29              
  Lines        1149     1156       +7     
  Branches      327      329       +2     
==========================================
+ Hits         1066     1073       +7     
  Misses         79       79              
  Partials        4        4
Impacted Files Coverage Δ
lib/utils/getSocketServerImplementation.js 90.9% <100%> (+1.43%) ⬆️
lib/utils/runOpen.js 100% <0%> (ø) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 26211fc...cf6e74a. Read the comment docs.

Copy link
Member

@alexander-akait alexander-akait left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it is extra checking and should be solved using schema-util instead adding checks in source code, we should search way how we can integrate this in schema util

@knagaitsev
Copy link
Collaborator Author

I think it is extra checking and should be solved using schema-util instead adding checks in source code, we should search way how we can integrate this in schema util

Switched to use of schema-util. I don't think it has the ability out of the box to check the parameter count of a function, but also that is not a check we really need.

Copy link
Member

@alexander-akait alexander-akait left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good job, one note

},
"required": ["constructor", "send", "close", "onConnection"],
"additionalProperties": false
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we can have one schema (put this inside original schema) for better maintenance

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@evilebottnawi The problem is that I couldn't find a way to test the prototype of a function with schema-utils when it matched "instanceof": "Function". I think it only looks at "properties" if the thing in question matches "type": "object", hence why I pass ServerImplementation.prototype into the schema

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unless you just mean make options.json into something like:

{
"defaultSchema": { ... },
"socketServerImplementationPrototypeSchema": { ... }
}

But that could be a breaking change if something else is using this schema.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hm we can rewrite schema-utils and allow to define own validator (where we can implement any logic), i will take care about this, let's keep this PR open, it is not high priority because we can improve documentation

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants