I'm using eslint, and in my configuration file I have "no-console": "off".
I want to turn it on for my CI system, so I've been using the command line (vue cli syntax):
vue-cli-service lint --rule '"no-console": "error"'
This doesn't work.
However, if I invert things (set error in the configuration, and pass off as a flag) it does work.
Anyone know why?
EDIT: it should probably look like vue-cli-service --rule 'no-console: 2'
PS: "error" may be working too I guess.
You can make a config in a lot of places but the usual one is probably .eslintrc.js in which you can write
module.exports = {
[...]
// add your custom rules here
rules: {
"no-console": "off",
},
}
As shown here: https://eslint.org/docs/rules/no-console
This one should work but it always depend on how your project is setup too.
Related
I have followed the advice of using ESlint, because it's suppossed to be helpful, when writing firebase functions code.
However, even the helloWorld function that is initialized by firebase is giving me errors?
Prettier and ESlint is conflicting as well - prettier adds spaces between brackets, but ESlint doesn't like that and again giving me errors?
I thought that I could fix this conflict by following this guide - https://dev.to/s2engineers/how-to-make-eslint-work-with-prettier-avoiding-conflicts-and-problems-57pi
But again I got this error, that I don't know what endOfLine rule supposed to do, but its giving me error -
Error: ../.eslintrc.json:
Configuration for rule "endOfLine" is invalid:
Severity should be one of the following: 0 = off, 1 = warn, 2 = error (you passed '"auto"').
my .eslintrc.js file:
module.exports = {
env: {
browser: true,
es2021: true,
},
extends: ["airbnb-base"],
parser: "#typescript-eslint/parser",
parserOptions: {
ecmaVersion: "latest",
sourceType: "module",
},
plugins: ["prettier"],
rules: {},
};
Am I missing something or ESlint is not helpful at all, why does spacing between brackets matter?
ESLint is definitely helpful, and personally I've never noticed a conflict between prettier and eslint. The question of bracket spacing is purely aesthetic if you ask me, and personally I prefer the idea that aesthetic questions are the domain of formatting (prettier), whereas best practices for the composition of the code itself is the domain of linting (eslint).
Concretely: I don't know what rules you're getting from airbnb-base, i'm not familiar. But I suggest you start with the recommended value for extends for a typescript project, something more like:
[
"eslint:recommended",
"plugin:#typescript-eslint/eslint-recommended",
"plugin:#typescript-eslint/recommended"
]
I'm thinking env and parserOptions are specific to your project so I'm not including those. Nonetheless ... I don't believe you really need the prettier plugin.
After migrating from VueCLI to Vite, I have to do the linting "manually" as far as I understand; correct me if I'm wrong.
As I only want to lint my .ts and .html files (I separate them even for components), I have this script in my package json:
"lint": "eslint --ext .ts --ext .html src/"
It found some issues like missing :key in loops, but it also shows me this error for each template:
error clear vue/comment-directive
And this is always the closing tag of any root elements within my template.html
If there is only one root element I get one warning for the file, if there are multiple root elements I get a warning for each closing tag.
I don't understand what this rule complains as, according its documentation, it is there for the eslint-disable comments, which I don't have in my templates.
I had the same issue but in nuxt with eslint, i just needed to update eslint-config and eslint-module:
"#nuxtjs/eslint-config": "^5.0.0",
"#nuxtjs/eslint-module": "^3.0.1",
source: https://github.com/nuxt/eslint-plugin-nuxt/issues/121
I've just updated my npm dependencies and I have the same error.
I was reading the eslint documentation and finally I've realized that you can remove the false error if you setup the rule in the .eslintrc.js config file.
this is my .eslintrc.js config file:
module.exports = {
root: true,
env: {
browser: true,
node: true
},
parserOptions: {
parser: 'babel-eslint'
},
extends: [
'#nuxtjs',
'prettier',
'prettier/vue',
'plugin:prettier/recommended',
'plugin:nuxt/recommended'
],
plugins: [
'prettier'
],
// add your custom rules here
rules: {
"vue/comment-directive": 0
}
}
add the rule "vue/comment-directive": 0 and that is!, the error message is removed!.
the possible values are:
0 means disabled
1 means warning
2 means error
Try to change it in your IDE to how it works
(In my case I've had to stop the server and re-run it every time that I've changed a value in this config file.)
I have the same error.
I was taught how to fix this error.
https://qiita.com/tashinoso/items/a72741ca8e2fd928ca77#comment-3e6cd674353056ecbb3a
module.exports = {
...
overrides: [
{
files: ["*.vue"],
processor: "vue/.vue"
}
]
}
Set this snippet on .eslintrc.js
"vue/comment-directive": ["error", {
"reportUnusedDisableDirectives": false
}]
Solve my issue, i wonder why. Solution from documentation
Node v12.20.0
This is a kind of a temporary fix that worked for me and I think it will work for you as well.
vue/comment-directive
This rule is included in all of "plugin:vue/base", "plugin:vue/essential", "plugin:vue/vue3-essential", "plugin:vue/strongly-recommended", "plugin:vue/vue3-strongly-recommended", "plugin:vue/recommended" and "plugin:vue/vue3-recommended".
ESLint doesn't provide any API to enhance eslint-disable functionality and ESLint rules cannot affect other rules. But ESLint provides processors API.
This rule sends all eslint-disable-like comments as errors to the post-process of the .vue file processor, then the post-process removes all vue/comment-directive errors and the reported errors in disabled areas.
All you need to do is add
eslint-disable-next-line vue/component-tags-order
this line as comment above anywhere you using comments within tags in each block you need to specify if comments are added.
For more information please visit:- https://eslint.vuejs.org/rules/comment-directive.html
I am setting up storybook for a project using .mdx format and I would like to set up eslint so that I can check for things like spaces, alphabetical ordering and other things.
I have tried to set up this https://github.com/mdx-js/eslint-mdx and it seems that I have, but when I run eslint . --ext mdx, I get the following errors in one of my stories.mdx files:
Could someone please point me to a good resource to solving this or tell me what I am doing wrong?
Cheers
I found this issue on their github page that fixed the issue for me. Basically we use "overrides" in .eslintrc to assign the correct parser to mdx files, like so:
{
...,
overrides: [
{
files: '*.mdx',
extends: 'plugin:mdx/recommended',
},
],
}
I want to be able to disable the rules that --fix fixes when running eslint in a console for a repo. The reason for this is because --fix leads to undesirable behavior for our jsdoc eslint rules. It creates invalid or sometimes empty jsdoc in our project- which typically leads to even more eslint rules (due to our configuration) and leads to tons of manual fixing or removal.
I want to just run --fix without it touching any jsdoc rules so that I can complete jsdoc manually- while eslint fixes all the rest of the rules.
I came across this SO question- but package mentioned in the answer does not support non-core plugins.
ESLint autofix ignore rule
Is there anything I can do short of modifying my eslintrc file every time I run the linter or using vscode for linting and modifying the config for the web editor instead? Its not a big deal for newer files- but linting legacy files is a chore when there's hundreds of spacing errors that I can't automatically fix easily.
Using an .eslintrc.js file you can do something like this:
const isFixMode = process.argv.includes('--fix');
const config = {
rules: {
'no-console': 'error',
...(isFixMode && {
'no-console': 'warn',
}),
},
};
module.exports = config;
Technically, that already exists, right? If a user wants to avoid auto-fixing a particular rule, they can use:
eslint somedir --fix --rule "somerule: 0"
Or, if they want to whitelist a set of rules, they can use &nbps --no-eslintrc and specify rules directly or use --config and point to a particular config that they want to use for fixes.
Ok here’s another idea. Convert you .eslinrc file into .eslintrc.js. This will allow you to programmatically set eslint config.
Then you could use the commander library to detect the —fix flag and set a Boolean to determine which eslint rules you would like to disable.
What worked best for me was setting the rule to warn and afterwards run.
eslint . --fix --quiet
It is not an error anymore, but better than getting my code broken by a erroneous fixer.
console.log statements output nothing at all in Jest. This was working for me yesterday, and all of sudden, it's not working today. I have made zero changes to my config and haven't installed any updates.
I'm not using the --forceExit option. Still seeing this issue.
Jest suppresses the console log message by default. In order to show the console log message, set silent option to false at the command line
set --silent=false in the command line:
npm run test -- --silent=false
You can run both options together like this --watch --verbose false if you want to also be watching the files and see the output.
for one time runs just do --verbose false
As per comment on https://github.com/facebook/jest/issues/2441,
Try setting verbose: false (or removing it) in the jest options in package.json.
This is a pretty old question and still there's no accepted answer. However, none of the suggested solutions worked for me (settings like --silent --verbose etc.). The main problem is that Jest changes the global console object. So, the easiest solution is to not use the global console object.
Instead import dedicated log functions from the console module and work with those:
import { error } from "console";
error("This is an error");
As easy as that.
Try using console.debug() instead.
Run console.debug('Message here', yourValueHere) inside test function and it should show in the console output when running test script. You can verify if it works using Ctrl+F and find Message here in the standard output.
This does the trick of showing output in the console, while it is not an answer quite on how to use console.log I understand.
I am running #testing-library/jest-dom and jest-junit 12.0.0 as devDependencies.
jest-junit has a minimal configuration of
"jest-junit": {
"usePathForSuiteName": "true"
},
in package.json. This is mainly to configure coverage reporting.
jest is configured like this:
"jest": {
"testMatch": [
"**/__tests__/**/*.[jt]s?(x)",
"**/?(*.)+(spec|test).[jt]s?(x)",
"!**/utilities.ts",
],
Check for your command line flags in package.json to see that you don't have --silent in there.
in addition to --verbose option which can cause this as mentioned, be aware that the --watch may also cause this bug.
One of the potential reason that logging is not printing is due to console.log has been mocked. Something as below
// jest-setup.js
global.console = {
// eslint-disable-next-line no-undef
log: jest.fn(), // console.log are ignored in tests
// log: console.log,
// Keep native behaviour for other methods, use those to print out things in your own tests, not `console.log`
error: console.error,
warn: console.warn,
info: console.info,
debug: console.debug,
};
// package.json
"jest": {
"preset": "react-native",
"moduleFileExtensions": [
"ts",
"tsx",
"js",
"jsx",
"json",
"node"
],
"setupFilesAfterEnv": [
"#testing-library/jest-native/extend-expect",
"<rootDir>/src/config/jest-setup.js"
],
"testMatch": [
"<rootDir>/src/**/__tests__/**/*.test.{ts,tsx}"
]
},
This is commonly used if you wish to disable console.log in jest
Also be sure that your jest config does not have silent: true. In my case, I didn't realize that someone else had added that to our config.
I don't see it in the list of config options, but the command line flag is documented here.
If using Webstorm with Jest configuration, click on the file name instead of the test name.
Having tried a few of the config options in the previous replies, using console.debug() instead of console.log() worked.
In my case, the issue was caused by [only] flag in:
it.only() or test.only('some text',()=>{})
According to the v27 docs silent is what you want here. verbose false (the default) prevents Jest from outputting the result of every test in a hierarchy while silent true (the default) will:
Prevent tests from printing messages through the console.
Use npx jest --silent false if you want to run Jest with that option from the CLI. Tested this just now with console.log and it works as expected.
Tried the advice given regarding jest config settings to no avail. Instead, in my case, the issue seemed related to not awaiting asynchronous code:
test("test", async () => {
console.log("Does output")
new Promise(resolve => {
// some expectation depending on async code
setTimeout(() => resolve(console.log("Does not output")) , 1)
})
})
Rather, awaiting the promise does output the async log:
test("test", async () => {
console.log("Does output")
await new Promise(resolve => {
// some expectation depending on async code
setTimeout(() => resolve(console.log("Does output")) , 1)
})
})
Possibly related background:
https://github.com/facebook/jest/issues/2441
Try using console.info() which is an alias for console.log(). I tried almost all the above answers but still console.log() didn't worked for me by any means. So, used console.info() which did the work.
This is what worked for me: jest --verbose true
In my case the problem was that the logs where made when the module is required, so before the start of an actual test case. Change from a top-level import to using require inside the test case fixed the problem.
In my case the problem was importing the functions from the compiled version (present in dist folder) instead of the src folder. And therefore it was using the old version. So rebuilding the project and/or importing from src fixed my issue.
On MacOS with jest version 26.6.3 I had to append --silent="false"
renaming my file to index.test.js from index.spec.js did the trick for me.