-
Notifications
You must be signed in to change notification settings - Fork 682
Consume Linter-Plus #12
Comments
One objection I have to the By comparison, |
I fail to think of a reason to choose |
I should be able to write a unit test for my linter provider that does not depend on the consumer. If I were to do that today, I would have to mock out constructors for This is a real issue. Note that today we have to disable our tests for our This is because The build flakiness is not worth it. Also, passing in constructor functions is not the cleanest thing to do, IMHO. You could just as easily pass in some sort of factory with methods like Further, your current contracts are not future-proof. That is, what happens when you want to start adding more parameters, more of which are optional? Your param list will become a mess. It would be easiest to represent each type as an object literal (at least from the provider's perspective) so that the consumer can recognize more properties over time, but older providers will still work. In sum, let providers return object literals, and internally, you can convert them to |
Thank you for providing a valid reason. I agree that Error and Trace constructors are not future proof, It would introduce complications when we add new parameters to constructors. On a side note, createError isn't really the cleanest way to do this, so I am gonna make linter-plus accept Error like Objects very soon after the PR mentioned above has been accepted. |
@bolinfest That new API has landed in the master branch. You can check out the new API in README. It's right according to what you suggested. |
@bolinfest The original linter has been depreciated and will be removed soon, all packages are advised to switch to plus API. |
Fixed in 1fc2358. Though please take note of https://github.com/AtomLinter/linter-plus/issues/87. |
… it re-renders Summary: Needed for request sender modal. Currently re-renders with a new initialValue prop don't actually cause the initialValue of the component to change.... Reviewed By: jgebhardt Differential Revision: D3890809 fbshipit-source-id: 7c04319eeb3cb8615d04716c6c1405ee10b55057
Summary: This implements: stepOver, stepInto, stepOut, resume, setPauseOnExceptions, evaluateOnCallFrame, Runtime.getProperties So essentially everything important. I've left out async break for now since it's kind of a hassle to implement correctly, and gives comparatively little benefit. Reviewed By: jgebhardt Differential Revision: D4093899 fbshipit-source-id: 4485affcccfaa34a66d05c5e354f9ac69a01b970
This is a meta bug about replacing AtomLinter with it's rewrite Linter-Plus, This rewrite features an extremely easy and flexible to use API along, which removes almost all of the limitations, including the complete project linting for hack.
Linter-Plus provides it's providers three types of messages
That, when consumed properly results like this
![screenshot from 2015-05-27 09-02-29](https://cloud.githubusercontent.com/assets/4278113/7841067/266c448a-044f-11e5-957a-b3d99cc11701.png)
Fixes #1
Fixes #5
Fixes #6
Fixes #7
Fixes #8
Blocked on AtomLinter/linter-plus#6 (it's ready to ship, will be shipped in a few hours maybe?)
The text was updated successfully, but these errors were encountered: