Found these related diffs:
https://secure.phabricator.com/D13557
https://secure.phabricator.com/D12198
https://secure.phabricator.com/D15124
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Mar 18 2017
ESLinter it the best linter in the JavaScript world. Are there any plans on adding support for it in the near future?
Mar 10 2017
Feb 28 2017
Feb 26 2017
For the record, you can work around the problem as such:
{ "linters": { "filename": { "type": "filename", "exclude": ["(\\+)", "(\\@)"] } }
Feb 2 2017
Is there any plan to add support for this in the near future?
Jan 30 2017
This is all frozen until we sort it out more generally.
@epriestley I like the work going on to externalize the linters, and I understand why you would merge the tasks.
Jan 1 2017
In T10038#150670, @epriestley wrote:Do you see there being a "Blessed" foo-linter (maybe as a repo on this instance?), or will there be multiple foo-tributes fending themselves in the wilds of github?
This is all still pretty early, but I imagine this instance mostly just collecting packages into a directory for now. The actual source might be on GitHub, but you'd be able to search this instance to find all foo-linter extensions by authors who had bothered to register their packages.
In some cases, we'd likely pull linters out of arc and turn them into Phacility-Published extensions (secure.phabricator.com/phacility/foo-linter) which we'd sign. These would be "blessed", as long as you continue trusting our signing keys.
In some cases, I'd like to "soft-bless" extensions as "safe, but don't come to us for support" with some sort of "Community Badge of Quality" key. For example, you might publish a secure.phabricator.com/cburroughs/foo-linter) which we'd sign in an advisory way which mean "we looked at the code, it seems fine, but we aren't taking bug reports for it". The UI and arc install would show users that someone they trust also trusts this code.
In some cases, untamed wilds, but collected in one place and searchable, with signing and a consistent toolset.
If nothing is blessed, you may have to make a decision like this yourself:
$ arc install foo-lint Query "foo-lint" matches multiple packages: secure.phabricator.com/alice/foo-lint secure.phabricator.com/bob/foo-lint None of these packages or vendors are signed by anything you trust. Which package do you want to install?But I think that should be OK. And we can do some level of positive and negative curation (advisory signing on good packages, disabling bad packages)..
You'll also be able to have an internal package directory for your company's stuff, so you can just publish internal things to it and then everyone can use standard tools to manage extensions.
Some day far in the future I could imagine the package directory integrating with other applications (e.g., giving each package its own repositories and tasks, like GitHub) but that's definitely far in the future. I expect most extensions (like linter bindings) to be small so they wouldn't get much benefit (e.g., 100 lines of code updated a couple times a year) and large extensions (eventually, third-party applications) to probably want to self-host on their own Phabricator instances in most cases.
The immediate goal is just fixing the problem that distributing extensions is a huge pain and all solutions have major downsides, with "convince the upstream to accept the extension" being the best option for everyone but us. The new distribution mechanism would be:
$ arc lint Okay, automatically installing all the extensions this project needs. (...prompts if you need to trust new stuff...) Done! ... nice lint outputWhich fixes distribution. In the long run, there's a lot we can do to build stronger ecosystem tools, but I'm less worried about tackling that stuff today than I am about moving distribution to a broadly reasonable mechanism.
Dec 14 2016
In T10038#203547, @cspeckmim wrote:@rscircus - this task (like I assume most tasks here) needs paid prioritization to move forward. see https://secure.phabricator.com/w/prioritization/
Oh really? Nice to hear, that I'll get monetary appreciation for contributing. 😉
Dec 13 2016
At least today, our error rate on this seems so low that it probably isn't worth implementing. We could take another look at it if we see more of it in the future (perhaps after we begin encouraging application development), but we haven't seen more of this that I can recall recently.
Dec 11 2016
@rscircus - this task (like I assume most tasks here) needs paid prioritization to move forward. see https://secure.phabricator.com/w/prioritization/
It seems, this task/problem has truly no priority, as @epriestley mentioned in his task description already. After skimming through related T5055, that idea reminded me of https://aur.archlinux.org/.
Dec 10 2016
Dec 9 2016
You can disable just the LINT_BAD_CHARSET function and still use the rest of TextLinter by adding the following to the .arclint file:
Nov 29 2016
I know this is more than a year old but...
Nov 16 2016
Nov 14 2016
Nov 8 2016
In T6653#167413, @maccath wrote:For reference and the benefit of people Googling how to configure a script and regex linter, here is a full example (using sass-lint):
.arcconfig file:
{ "linters": { // snip ... "sass": { "type": "script-and-regex", "include": "(\\.scss$)", "script-and-regex.script": "sh -c 'sass-lint -v \"$0\" || true'", "script-and-regex.regex": "(^((?P<file>.+): line (?P<line>[0-9]+), col (?P<col>[0-9]+), (?P<severity>[^\\-]*) - (?P<message>.*) \\((?P<name>[a-z\\-]+)\\))$)m" } }
Nov 2 2016
If it is impossible to reproduce this issue without writing custom code, we won't accept a patch for it.
I know that upstream can't offer support for fixing this, but would you be at all willing to accept a patch that addresses this issue?
Oct 29 2016
seems this is due to I didn't add the --lintall option,
the change is one line removal (existing file at the base commit)
thus it's considered as not concerned, but it is concerned actually because I didn't remove the entire function
Oct 8 2016
Oct 7 2016
I have a patch to Arc that will use a non-printable control character (INFORMATION SEPARATOR THREE) instead of | for the separator.
Oct 4 2016
Sep 27 2016
Sep 26 2016
Sep 6 2016
I solved this for my purposes here. It might be a decent starting point for you: https://github.com/andypoorman/arcanist/commit/f1eb928c462029397fff9a1f1c42122a6d54bc9f
Aug 30 2016
Aug 29 2016
In T11517#192337, @rayzyar wrote:In T11517#192332, @michaeljs1990 wrote:I've just tried to reproduce again, seems my steps cannot reproduce it.
I couldn't find out a good way to reproduce this bug.
Here is what I found :
when I change my existing code (removing the comment of an exported variable or method), arc lint at root git directory doesn't trigger the ADVICE
however arc lint xxx/xxx.go could trigger the lint ADVICEAnd I tried to copy the same code to try to reproduce this, it works perfectly with arc lint at root git directory.
BTW, I am using some extension, https://github.com/zerodiff/traphicThank you a lot for looking into this
In T11517#192332, @michaeljs1990 wrote:
I've just tried to reproduce again, seems my steps cannot reproduce it.
I couldn't find out a good way to reproduce this bug.
Here is what I found :
when I change my existing code (removing the comment of an exported variable or method), arc lint at root git directory doesn't trigger the ADVICE
however arc lint xxx/xxx.go could trigger the lint ADVICE
Aug 28 2016
You are going to have to post more information. I am able to correctly see the error you posted following these steps.
Can you post your arclint file
See Planning for timelines on how we work. If this issue is urgent and blocking your company, see Support Resources for prioritization options.
@chad could u take a look again
Aug 23 2016
In T11517#191349, @chad wrote:Please follow the instructions in Contributing Bug Reports. This is not a valid report without version information and step by step reproduction information.
Please follow the instructions in Contributing Bug Reports. This is not a valid report without version information and step by step reproduction information.
Aug 17 2016
I also encounter issues configuring the script and regex linter.
However, I use regex101 to test my regex, so I know that works.
If I remove the || true exit code workaround, I see that the right commands are issued, with the right stdout, so that works as well.
Aug 11 2016
We don't currently plan to bring any more third-party linters upstream. Instead, we're going to make it easier for users to write and distribute linter bindings themselves.
Aug 5 2016
Aug 4 2016
If it functions identically to pylint, then you can use the same linter binding and set bin to the new executable...
Aug 2 2016
Thanks. Appreciate the quick fix on this.
Aug 1 2016
Jul 30 2016
Jul 21 2016
Jul 4 2016
Jul 3 2016
In T11105#179265, @hach-que wrote:This is solved with D11688, but it needs to be turned on globally (at the moment it's a per call option, which was added so that internally our custom unit test runner wouldn't deadlock).
Jun 30 2016
Jun 28 2016
This is probably better implemented as "content" ("content matches regexp...") than the narrower "shebang".
Jun 25 2016
Jun 18 2016
I just encountered the same problem and this solution worked for me as well. Thanks @DheerendraRathor !