Enh semi standard and others

[andrewjaykeller]

1.4.0

New Features

• Add timeOffsetMaster to object emitted when bad time sync.

  Enhancements

• Implement and adapt semi-standard code style. Closes #83

  Bug Fixes

• Fixed log statement on impedance setting function
• Remove event emitter with time sync on reject of sync clock full

[codecov-io]

Current coverage is 93.33% (diff: 95.27%)

Merging #88 into master will increase coverage by 0.64%

@@             master        #88   diff @@
==========================================
  Files             4          4          
  Lines          2186       2174    -12   
  Methods         128        126     -2   
  Messages          0          0          
  Branches        478        476     -2   
==========================================
+ Hits           2026       2029     +3   
+ Misses          160        145    -15   
  Partials          0          0          

Powered by Codecov. Last update 6fd9ddf...a6eb7e2

[andrewjaykeller]

@baffo32 what are your thoughts on this PR in regards to #82 and your work on it? I can remove the semi standard adoption from this PR if it will mess up your PR too much.

[baffo32]

wow !

Maybe I should redo #82 on top of this. It's a pretty small change, conceptually, and this looks huge at first glance. Might be less work than trying to merge them.

[baffo32]

are you automatically applying semi-standard with a tool, such that I could make the same automatic changes to ease merging, or manually handling each of the complaints of the linter?

[andrewjaykeller]

Hey! Yes i am using a standard tool that will check to make sure everything is listing properly called semi-standard

By simply running the command semistandard we are able to verify everything is listing correctly.

I'm not sure what to do here... my gut says:

1. Remove semi-standard from this PR and merge in the small patch to bump to v1.3.3
2. You rebase off of that and continue building with no issues
3. After we merge #82 we rebase the semi standard adoption over that, changing only the lines of code you add in #82

Thoughts?

[baffo32]

I think it would definitely be helpful to separate the patch from the restyling.

If your restyling is simply a run of semistandard --fix, then I can run that on my branch, too, and it will become similar and the merge may become relatively painless. But if the restyling is mostly manual changes that aren't easily reproducible, then one of us will have to go through and manually propagate things by hand.

[andrewjaykeller]

Yea there was a bunch of manual changes. Let's go with my three step suggestion and you can essentially ignore this for the time being!

[baffo32]

Could you merge this into either master or a new 1.4.0 branch, so that changes for 1.4.0 can be separated out into different pull requests and commits?

I think for tests to run smoothly for #82 some other fixes will be needed first. Those fixes should probably happen on top of this branch, since they would be new code.

[andrewjaykeller]

@baffo32 done!