We are trying to use grunt-lesslint in our project, as our UI developer is comfortable fix errors in less file. grunt-recess seems more powerful but not sure if it can point errors in less file itself. I am unable to comprehend enough from lesslint page, and there do not seem to be many examples. Does anyone know the following:
How to prevent lesslint from displaying on the console. I use formatters and the report file is generated, but it also prints on console, which I do not want to.
How to make lesslint fail only in the case of errors (not warnings). Also csslint seems to report errors also, while lesslint mostly gives warnings only, why is that so? Does lesslint throw errors as well? How to make it fail only in case of errors?
I tried using 'checkstyle-xml' formatter, but it does not seem to use it (I have used in jshint and it gives a properly formatted xml, which it does not give for lesslint).
Is it possible to compile less (many files or directories) in conjunction with lesslint? Any example?
Thanks,
Paddy
I'd say it's more of a common practice to display stdout for this kind of thing; the JSHint plugin does it, as does any other linting plugin that I've used. If you get in another developer that uses Grunt they'll probably expect stdout too. If you really want to override this, use grunt-verbosity: https://npmjs.org/package/grunt-verbosity
Again, this is a convention in Grunt; if a task has any warnings then it fails. The reason being if you lint a file and the linter flags something up it should be dealt with straight away, rather than delay it; six months time you have 500 errors that you haven't fixed and you're less likely to fix them then. Most linting plugins allow you to specify custom options (I've used CSS Lint and that is very customisable), so if you don't like a rule you can always disable it.
This should work. If there's a bug with this feature you should report it on the issue tracker, where it will be noticed by the developers of the plugin. https://github.com/kevinsawicki/grunt-lesslint/issues
Yes. You can set up a custom task that runs both your linter and compile in one step: something like grunt.registerTask('buildless', 'Lint and compile LESS files.', ['lesslint', 'less']); note that you'll have to install https://github.com/gruntjs/grunt-contrib-less to get that to work. Also note that, failing linting will not compile your LESS files; mandate that your code always passes the lint check; you'll help everyone involved in the project.
Related
I know it can be done, but I'm having trouble getting it working. I'm still finding my feet with Haskell.
I tried using postgresql-typed, but it wouldn't compile. They don't enable the QuasiQuotes extension, so I don't understand how their code would ever compile. It also fails with an error on the useTPGDatabase statement. I cloned the library's source code from Github, but their tests failed to compile using stack with exactly the same errors.
I considered using hasql-th, but it's not on stackage.org, which immediately puts it in the "too hard basket.". I considered switching to nix but that seems like even more effort.
Does somebody have a reliable recipe for getting an environment working that type-checks SQL at compile time in Haskell?
I considered using hasql-th, but it's not on stackage.org, which immediately puts it in the "too hard basket."
All you need to do is add the latest version of hasql-th to the extra-deps section of your stack.yaml file and all other deps that Stack will suggest to you when you build.
In the end your stack.yaml file should look something like this:
resolver: lts-17.9
extra-deps:
- hasql-th-0.4.0.8
- headed-megaparsec-0.1.0.4
- postgresql-syntax-0.3.0.3
Anticipating a question in the spirit of "Why is it not listed on Stackage?" It's just that nobody has gotten to list these packages yet.
I've got a code formatting extension, with format on save enabled. Unfortunately, it annoyingly gives me a warning every time I save but my program fails to parse. This information is redundant, since there are other packages which inform me of the error in a much less intrusive way.
Is there any way to block all notifications/warnings from a particular package?
This is not possible as of VS Code 1.18.
Please file an issue against the responsible extension so that they can fix this
Is there a lint for Elixir (like for Javascript) which checks that every function has a type specification?
There is an Erlang compiler switch, +warn_missing_spec, which does this, but I'm having trouble getting it to work with Elixir at the moment, I think there is a bug with it's parsing of the ELIXIR_ERL_OPTS environment variable which is converting +warn_missing_spec into -warn_missing_spec which isn't a valid compiler option. I'm going to open an issue on the tracker, but thought you might like to know that this does indeed exist.
EDIT: As José mentioned below, the correct flag is ERL_COMPILER_OPTIONS. You can enable the missing spec warning during compilation by doing the following:
ERL_COMPILER_OPTIONS="warn_missing_spec" mix compile
Keep in mind you may get superfluous warnings from Elixir itself, for functions like __MODULE__. It should still be useful though. One last thing to note, I discovered this morning that there is a problem using this flag with mix compile, and that it's currently only warning about mix.exs. This is being fixed, and may even be fixed by the time you see this, but it's something to be aware of.
When using Common Test with Erlang on Windows, I run into a lot of bugs with Common Test and Erlang. For one, if there are any spaces in the project's path, Common Test often fails outright. To workaround this, I moved the project to a path with no spaces (but I really wish the devs would fix the libraries so they work better on Windows). Now, I got Common Test to mostly run, except it won't print out the HTML report at the end. This is the error I get after the tests run:
Testing myapp.ebin: EXIT, reason {
{badmatch,{error,enoent}},
[{test_server_ctrl,start_minor_log_file1,4,
[{file,"test_server_ctrl.erl"},{line,1959}]},
{test_server_ctrl,run_test_case1,11,
[{file,"test_server_ctrl.erl"},{line,3761}]},
{test_server_ctrl,run_test_cases_loop,5,
[{file,"test_server_ctrl.erl"},{line,3032}]},
{test_server_ctrl,run_test_cases,3,
[{file,"test_server_ctrl.erl"},{line,2294}]},
{test_server_ctrl,ts_tc,3,
[{file,"test_server_ctrl.erl"},{line,1434}]},
{test_server_ctrl,init_tester,9,
[{file,"test_server_ctrl.erl"},
{line,1401}]}]}
This happened in sometimes in Erlang R15 and older if the test function names were either too long or had too many underscores in the name (which I suspect is also a bug) or when too many tests failed (which means Common Test is useless to me for TDD). But now it happens on every ct:run from Common Test in R15B01. Does anyone know how I can workaround this? Has anyone had any success with TDD and Common Test on Windows?
Given the last comment you might want to disable the buildin_hooks. You can do this by passing the following to ct:run/1 or ct_run
{enable_builtin_hooks,false}
That should disable the cth_log_redirect hook and maybe solve your problem during overload.
I am having a CI setup with incremental build. As part of the static checking, I am planning to configure a incremental PC Lint report - This report ignoring all other previous Lint report should provide the errors induced in the new code only. Is there any tool which would do this?
Any hint on the relative area to explore would help us.
I tried report diff'ing. But since the line number would vary from last check-in, would not get the actual incremental error introduced.
I am using Linux for my project build, and using Windows for PC Lint report generation.
Regards,
Wouldn't it be easier to just fix all the reported errors, and have a strict policy against creating new ones? That way you don't need to worry about diffs which by the nature of the problem is going to be hard to impossible.
You could write a script that takes the warnings from lint, removes the line numbers and adds a few lines from the source code around where the warning occurs. Diffing this would show all new lint warnings. One flaw in this, is that it would also show any warnings where source was modified near an existing warning without fixing the warning. On the other hand, this might actually be useful.
Years ago, I saw a utility on BDS Unix that would take your compiler errors and stuff them into your source code as comments. Which might be useful for this exercise. Unfortunately I can't remember what it was called.