I am running Mocha tests (with Chai as an assertion library).
At the moment JSHint fires a warning every time it encounters a line like this one:
expect(err).to.be.null;
The reported problem is:
Expected an identifier and instead saw 'null' (a reserved word).
Is there any relax option for JSHint to fix this issue?
At the moment the only solution I have only found is to include the special option at the beginning of the file:
/*jshint -W024 */
The problem with that is that it needs to be included in every test file (and I would rather separate JSHint options from the code itself). I do not seem to have found much in the options list.
You can put the following settings:
{
"expr": true,
"es5": true
}
in a .jshintrc file at the top level of your test suite. I'm still on version 1.1.0 of jshint and thus need both settings but apparently version 2.0.0 and above has es5 set to true by default. The expr setting is documented here. There no longer a reference for es5 probably because it is default and cannot be turned off. (Jshint 2.0.0 will raise an error if you try to set it manually.)
The way jshint operates when checking a file is by looking for a .jshintrc file in the same directory as your file. If not found, then it looks one level up. If not found there, then it looks one more level up, etc.
I actually realized that I had an enforcing option enabled.
To fix it I only had to set:
"es3": false
(Since it is the default, the same can be obtained removing the option completely)
Related
Existing answers about disabling ESLint answer the question "How can I disable ESLint in one file, a pattern of files, or a directory of files?" Is there an easy way to just stop a project from checking ESLint at all?
My goal here is to run a Cypress test with a debugger; command and possibly many other syntax errors due to temporary commenting out. I want to be able to test partially complete code and then toggle type checking back on. Bonus points if the solution stops TypeScript checking as well.
Things I tried that didn't work:
adding /* eslint-disable */ to cypress/support/e2e.js
launching cypress open with DISABLE_ESLINT_PLUGIN=true
My app is using create-react-app.
As a workaround for this, you can disable the no-debugger rule in development but leave it on in production, as per https://stackoverflow.com/a/62592912/733092:
'no-debugger': process.env.NODE_ENV === 'production' ? 'error' : 'warn'
Another workaround is to put the per-file disable text in a PyCharm Live Template so you can auto-type
/* eslint-disable */
// #ts-nocheck
at the top of the file you're in.
I'm using enumerators (experimental) in my project. Pub Build (Generate JS) in my Dart Editor does not work due to the enums. In my console, this command:
dart2js file.dart --enable-enum
does work, but it is inconvinient to do it through the console. Is there any way to add arguments to the default command in Dart Editor (--enable-enums) so it'd allow it to compile into JS?
Running it by default in Dartium works and when copying and pasting the server url (http://localhost:8080/index.html), the dart2js is triggered and it starts working (after average compilation time).
EDIT: Yes, I have enums enabled in my editor.
EDIT2: To enable enums in dart2js, I have this transformer in pubspec.yaml:
transformers:
- $dart2js:
commandLineOptions: [--enable-enum]
However, I get this error in a file, which uses enums:
Directive not allowed here.
part of thing;
^^^^^^^^^^^^^^^^
[Info from Dart2JS]:
It's weird that it works in the console with the same arguments and not in the editor.
I have filled a bug report here.
As of 2016, the enumerators are fully implemented.
I was wondering about the BII_IMPLICIT_RULES_ENABLED flag which I had switched off in one of my CMakeLists.txt files, in order to get an OpenGL related block to compile on a Mac, following a suggestion from biicode. This setting is still there and everything works perfectly, but I would like to find out more about it. Could someone explain what it does exactly?
Thanks!
BII_IMPLICIT_RULES_ENABLED activates the addition of system libs to the target that has included certain headers. For example, if your code contains an:
#include "math.h"
And you are in *nix systems, then the library "m" (libm) will be added to your target via TARGET_LINK_LIBRARIES.
You can see the headers that are processed in your cmake/biicode.cmake file, in the HANDLE_SYSTEM_DEPS
My recommendation: Put it to False whenever possible, and handle the required system libs yourself, exactly what you have done. It is something that will be deprecated soon, or at least set to False by default to new projects. This option sometimes causes troubles, if something fails or there is a bug in biicode.cmake, e.g. in the past it tried to add libm to targets also in windows. It will be gradually deprecated and probably substituted by some CMake macros hosted (as in http://www.biicode.com/biicode/cmake) that could be used by users if they decide to, but not automatically as it is done now.
I'm using PhpDocumentor (1.4.4) & NetBeans (7.1). When I generate the php documentation I get an error/warning on the top of the documentation (and in documentation in certain places too):
"Strict Standards: Only variables should be passed by reference in ..."
Does anybody know why is this problem?
Formerly (not on this computer) I didn't get this message.
The root cause here is that phpDocumentor itself if PHP4 code. I'm guessing you are executing it on PHP5, and are thus seeing runtime notices based on your error reporting level in php.ini.
This is nothing to worry about with regard to using phpDocumentor, nor is it something to worry about in your source code that you are documenting.
PHP Documentation states:
The following things can be passed by reference:
- Variables, i.e. foo($a)
- New statements, i.e. foo(new foobar())
- References returned from functions
No other expressions should be passed by reference, as the result is undefined.
This has been the case since PHP 4.0.4. Most likely your source code is out-dated and needs changes.
At last the solution:
I used smarty themes (HTML:Smarty:*) and there was no errors.
Solved.
I recently installed Chirpy v2.01 for Visual Studio 2010 and am very excited about the features it offers. I'm running into some issues in the LESS domain, however.
As a first step, I copied over my existing .css file to a new LESS file. I immediately am getting two errors. The first is due to a CSS "filter" property that I have set:
div.someClass {
filter: progid:DXImageTransform.Microsoft.gradient(startColorstr='#aaaaaa', endColorstr='#000000');
}
This apparently is because the filter value is not technically valid css. LESS has a workaround for this, via escaping. Adding a tilde in front of a quoted section tells LESS to keep the value as-is. The following change should resolve the issue:
div.someClass {
filter: ~"progid:DXImageTransform.Microsoft.gradient(startColorstr='#aaaaaa', endColorstr='#000000')";
}
Upon saving the file, I still receive an error in the visual studio error console along these lines:
Error 54 Expected '}' on line 2 in file 'C:\Users\Administrator\Projects\Project\Content\test.chirp.less':
[1]: body {
[2]: filter: ~"progid:DXImageTransform.Microsoft.gradient(startColorstr='#aaaaaa', endColorstr='#000000')";
----^
[3]: } C:\Users\Administrator\Projects\Project\Content\test.chirp.less 2 5 Project
The .css files are never generated so long as this error comes up. I came across the following site that seems to describe the issue I'm having, but in a more generic DotLess .NET package. I tried adding this package to my project, but it didn't make a difference. It also looks like it relies on the server to handle the .less to .css conversion, instead of the IDE, as chirpy does.
The second error that I constantly receive, though it doesn't seem to actually stop the generation of the .css files, is the following:
Error 53 Fatal error, cannot continue: null cannot be converted to an object C:\Users\Administrator\Projects\Project\Content\test.css 1 1 Project
I'd really love to use the LESS functionality that Chirpy offers, but until I can figure out why these errors are happening, I'm limited to using it for mash.
you have to understand that Chirpy is simply using dotlesscss internally to transform the less into css.
So any bug in dotless also applies to Chirpy.
We have patched that bug quite recently and a new dotlesscss version is upcoming.. But how long it will take until Chirpy updates to the new version is up to the Chirpy developers..
greetings Daniel
I wrote a similar VS extension that compiles less but it uses less.js directly and doesn't depend on dotless. Check it out.