The react-script uses typescript-eslint internally which trows warnings/error and you see it in the terminal where the app is running.
I did create react app with create-react-app --typescript and did set up a tslint.json as follow:
{
"defaultSeverity": "error",
"extends": [
"tslint:recommended",
"tslint-react",
"tslint-eslint-rules",
"tslint-plugin-prettier",
"tslint-config-prettier"
],
"jsRules": {},
"linterOptions": {
"exclude": ["node_modules", "dist", "build", "src/serviceWorker.ts"]
},
"rules": {
"prettier": [true, "./.prettierrc"]
},
"rulesDirectory": []
}
and a lint check script like "lint": "tslint -p tsconfig.json -c tslint.json 'src/**/*.{ts,tsx}'" in package.json.
But not all typescript-eslint from react-script is covered by tslint and the lint script passes while there exists some warning.
Should I completely dump the usage of tslint and go for eslint? If so can someone provide a snippet for the settings?
Or if Tslint has any plan to be update and cover all those warnings from typescript-eslint
Perhaps you could adjust your tslint configuration to get those warning it missed, but I don't think it is worth it.
For starters, as you note CRA has switched to eslint-typescript, and I think it is easier to just use the one officially supported linter rather then using both the old and the new.
Also, tslint is formally deprecated in favour of eslint-typescript so you are swimming against the stream and I doubt there will be updates. You might be able to get tslint to work as you want now, but probably not for the lifetime of your app.
The switch to eslint-typescript was announced almost a year ago and now that the major projects like CRA have also switched I think that early issues are resolved and it is time for all new projects to use it.
Related
Edit: This was a bug in 3.1.0 - upgrade to 3.1.1+ to get a working version of this feature.
create-react-app 3.1.0 is supposed to have support for customising the eslint warnings, as per: https://github.com/facebook/create-react-app/pull/7036
The documentation is here: https://facebook.github.io/create-react-app/docs/setting-up-your-editor#experimental-extending-the-eslint-config
I believe the rule setting I have in my package.json is correct because IDEA picks it up and no longer dislays the dot-location warning in the editor.
But npm start still complains with:
./src/Auth/AuthenticationProvider.tsx
Line 135: Expected dot to be on same line as property dot-location
My package.json is as per the documentation and I've added the EXTEND_ESLINT variable to the .env file.
My package.json config:
"eslintConfig": {
"extends": [
"react-app"
],
"rules": {
"dot-location": "off"
}
},
The environment variable is set in my .env file.
And the example failing source code looks like:
props.auth0Client.loginWithRedirect().
catch((e)=>{errorHandler(e)});
What am I doing wrong?
Am I misunderstanding how eslint config works, or maybe I'm wrong about what this new feature of create-react-app is actually supposed to do?
Please note: I don't want to add annotations to my code everywhere to disable the warning - the question is about customising the eslint config.
It appears you are not doing anything wrong and there is a bug in create-react-app 3.1.0. If you want to track progress, an issue has been filed in GitHub.
I used to build React apps starting with create-react-app, then I would install eslint with plugins and a custom config, run an eslint init, and add some custom scripts to run eslint and eslint auto fix easily and automatically on certain actions like a build. Create-react-app now comes with eslint already installed and "ready to go." In VS Code, I see the linter running in my "problems" tab. How do I now run eslint autofix? That is the main benefit of a linter in my opinion.
I use VS Code. I have spent some hours trying different ways to set up linters in create-react-app. I believe that the inclusion of eslint has changed the state of this quite a bit and made most of those posts simply outdated. I had a setup working for about a year using Prettier to avoid ejecting eslint, but an unresolved issue has caused that to stop working. So I have taken a step back to try to understand the state of the create-react-app dev environment now. Are folks using VS Code with create-react-app? If so, do you have autofix working?
I found one way to get an autofix on save in a create-react-app in VS Code. I don't know if it's the best one. It's simpler than I thought.
After running:
create-react-app my-app
Run:
npm install --save-dev prettier
Add to root directory:
.prettierrc
{
"tabWidth": 2,
"semi": false,
"singleQuote": true
}
Install VS Code prettier extension.
Find VS Code user settings json. Mine is:
{
"typescript.check.npmIsInstalled": false,
"window.zoomLevel": 0,
"editor.minimap.enabled": false,
"emmet.includeLanguages": {
"javascript": "javascriptreact"
},
"emmet.syntaxProfiles": {
"javascript": "jsx"
},
"eslint.alwaysShowStatus": true,
"editor.formatOnPaste": true,
"editor.formatOnSave": true,
"editor.formatOnType": true,
"files.autoSave": "onFocusChange",
"prettier.semi": false,
"prettier.tabWidth": 4
}
Now, if I save, I will get autofixes.
Most of the tutorials online assume that eslint is not already installed with create-react-app and/or that eslint and prettier must be integrated with plugins and an eslintrc file. My fix may be missing something, as it may not be making use of eslint or there may be conflicts between the two linters at some stage.
Goal
Be able to create a new project for react-native (using react-native init), and enabling flow checks on Visual Studio Code.
What I Did
I just created a new react-native project
react-native init iaptris
then opened Visual Studio code
cd iaptris
code .
I saw this errors
Whis these error descriptions (in italian, sorry)
Googling I concluded I must install Flow Extension for VsCode and I did.
I then disabled native checking for current workspace, setup file association and path to flow command
{
"javascript.validate.enable": false,
"files.associations": {
"*.json": "json",
"*.js": "javascriptreact"
},
"flow.pathToFlow": "C:\\Users\\mirko\\.vscode\\extensions\\flowtype.flow-for-vscode-1.0.1\\node_modules\\.bin\\flow.cmd"
}
Closed and restarted vscode on same workspace
The problem
At this point, errors disappeared, but also, removing a curly brace to throw a new syntax error, I do not see any errors. No errors.
Question
What else must I do now?
Actual solution, please post your answer if this is not the better method. And I think it's not the better method.
react-native init <project name>
open VsCode
disable Javascript -> Validate for the current workspace only (sorry if next image is in italian, but it's enough as reference)
install a plugin
yarn add eslint babel-eslint eslint-plugin-flowtype --dev
or
npm install eslint babel-eslint eslint-plugin-flowtype --save-dev
create a .eslintrc with following content
{
"parser": "babel-eslint",
"plugins": [
"flowtype"
],
"extends": [
"plugin:flowtype/recommended"
]
}
close and reopen vscode and the workspace
I have a Vue project generated by the Vue cli 3 and my hot reloading suddenly stopped working in my browsers. Changes made to the code are still picked up by the terminal, however, my browser is not picking up the changes. I have to manually refresh in order to pick up the new changes. As suggested by some others I manually set poll: true in my vue.config.js and I also tried to set the proxy, but both had no success.
Any suggestions to make this work again?
Update:
After some Vue updates, it suddenly started working again. I still don't know the reason for this. It might have been a bug in the vue-cli?
My problem was WDS
Console displayed:
[HMR] Waiting for update signal from WDS...
[WDS] Disconnected!
GET http://ip:port/sockjs-node/info?t=some-number
net::ERR_CONNECTION_TIMED_OUT sockjs.js?some-number
Solution for me was:
in
package.json
change
"serve": "vue-cli-service serve",
to
"serve": "vue-cli-service serve --host localhost",
or
add
module.exports = {
devServer: {
host: 'localhost'
}
}
to
vue.config.js
:)
HMR has problems in various environments, in those situations you can maybe help yourself with the poll option:
https://github.com/vuejs-templates/webpack/blob/develop/template/config/index.js#L21
var devMiddleware = require('webpack-dev-middleware')(compiler, {
publicPath: webpackConfig.output.publicPath,
stats: {
colors: true,
chunks: false
},
watchOptions: {
aggregateTimeout: 300,
poll: 1000
}
})
Seems I finally found it: my $cat /proc/sys/fs/inotify/max_user_watches was on 8192 and this helped me:
echo 100000 | sudo tee /proc/sys/fs/inotify/max_user_watches
Now Vue hot reload works without sudo and without poll ! ))))
One failure mode I've come across here is if you've managed to end up with multiple installations of webpack in your node_modules.
The reload relies on these two bits of code emitting events to each other:
webpack-dev-server/client/index.js
var hotEmitter = require('webpack/hot/emitter');
hotEmitter.emit('webpackHotUpdate', currentHash);
webpack/hot/dev-server.js
var hotEmitter = require("./emitter");
hotEmitter.on("webpackHotUpdate", function(currentHash) {
However, if you have multiple webpacks installed (e.g. a top-level one and one under #vue/cli-service) the require will resolve the first to ./node_modules/webpack/hot/emitter.js and the second to ./node_modules/#vue/cli-service/node_modules/webpack/hot/emitter.js which aren't the same object and so the listener never gets the event and reloads fail.
To resolve this I just uninstalled and reinstalled #vue/cli-service which seemed to clear the package-lock.json and resolve to the single top-level webpack.
I don't know if there's any way to ensure this doesn't happen -- however, it might be possible for vue-cli-3 to spot the situation and at least log a warning in dev mode?
[BTW adding devServer: { clientLogLevel: 'info' } } to vue.config.js was really helpful in debugging this.]
I faced the same issue (the console showed an error that said "[WDS] Disconnected") and here's what I did. Note that I was using the Vue UI tool for managing my project and I did not edit any config files.
Under Tasks/serve, I stopped the task.
I clicked the parameters button and in the input for "Specify host" label, I added the IP of my localhost i.e. 127.0.0.1 and in the input for "Specify port" label, I added 8080.
I saved the parameters and ran the server again from the tool.
Not sure why but this seemed to work for me. I'd love if someone can explain why it works.
I also have this WDS issue with each Vue project I make (kind of annoying, even with latest vue cli 4.5.0 and vue 2.6.11).
So the following solution is what I copy paste each and every time.
In vue.config.js file :
module.exports = {
devServer: {
// Fixing issue with WDS disconnected and sockjs network error
host: '0.0.0.0',
public: '0.0.0.0:8080',
disableHostCheck: true,
// End of fix
}
}
What was the cause in my case:
It seems that the value of: max_user_watches
in the /proc/sys/fs/inotify/max_user_watches
is affecting webpack => which is interfering with hot reloading.
To check your actual value
$cat /proc/sys/fs/inotify/max_user_watches
16384
16384 was in my case and it still wasnt enough.
I tried different type of solutions like:
$ echo fs.inotify.max_user_watches=100000 | sudo tee -a /etc/sysctl.conf
$ sudo sysctl -p
But it seems that even if I changed the value, when I restarted my PC it would go back to default one 16384.
SOLUTION if you have Linux OS(my case, I have Manjaro):
Create the file:
sudo nano /etc/sysctl.d/90-override.conf
And populate it with:
fs.inotify.max_user_watches=200000
It seems 200000 is enough for me.
After you create the file and add the value, just restart the PC and you should be ok.
Maybe this can help https://webpack.js.org/configuration/watch/#changes-seen-but-not-processed
"Verify that you have enough available watchers in your system. If this value is too low, the file watcher in Webpack won't recognize the changes:"
cat /proc/sys/fs/inotify/max_user_watches
"On macOS, folders can get corrupted in certain scenarios. See this article."
And in the link above you can check other known issues.
set NODE_ENV=development might solve your problem.
Adding NODE_ENV=development to your .env file will solve the problem.
I hope that this could be helping someone, I'd used of the terminal in my WebStorm and vue-cli-service didn't work, then I opened a normal terminal and that's it, maybe something in WebStorm didn't let the correct way in the vue-cli-service
I used proxy extension in my Firefox browser. Try turning that off if you have one
Please make sure you don't have any error in your code.
This happens usually because of error in any of our code files.
Just run
npm install -g #vue/cli-init
You can run vue-cli-service serve --public localhost
According the docs:
--public specify the public network URL for the HMR client
https://cli.vuejs.org/guide/cli-service.html#vue-cli-service-serve
This was my problem anyway, HMR was running on the network IP instead, for some reason. Causing CORS and connection refused issues.
For me More Tools >> Clear Browsing data in Chrome did the trick. Also try incognito before.
In Firefox everything was fine.
So before editing your vue.config.js take a look at the browsers.
I solved this problem by changing the versions of my dependencies and devDependencies:
"dependencies": {
"core-js": "^3.4.4",
"vue": "^2.6.10",
},
"devDependencies": {
"#vue/cli-plugin-babel": "~4.1.0",
"#vue/cli-plugin-eslint": "~4.1.0",
"#vue/cli-service": "~4.1.0",
"babel-eslint": "^10.0.3",
"eslint": "^5.16.0",
"eslint-plugin-vue": "^5.0.0",
"vue-template-compiler": "^2.6.10"
},
I am a webpack newbie and have a question about testing.
I have a project which uses webpack, typescript and karma as test runner and I would like to run my tests on every file change (e.g. in "watch" mode)
I am aware of karma-webpack and it works well when I run karma as own process (karma start ...)
But what I want is to integrate karma in the webpack flow.
So, from my naive point of view, I thought karma has to be defined in preloading of webpack (such as a linter).
But I found nothing....
I can not believe that this common workflow is not possible (run tests on every source change)
Can anybody of you give me a suggestion?
Time flies and it's June 2018 already. As there isn't much documentation about this online I want to give out my 2 cents.
I have currently a setup working where I bundle my tests with webpack a watch for changes in order to rerun automatically the tests.
I'm using karma-webpack using the configuration explained in the Alternative usage section and I think it's the proper way to solve the problem asked in the question.
karma.conf.js
{
...
files: [
// only specify one entry point
// and require all tests in there
'test/index_test.js'
],
preprocessors: {
// add webpack as preprocessor
'test/index_test.js': [ 'webpack' ]
},
...
}
test/index_test.js
// require all modules ending in "_test" from the
// current directory and all subdirectories
const testsContext = require.context(".", true, /_test$/)
testsContext.keys().forEach(testsContext)
Watching for changes of the whole bundle as #Adi Prasetyo suggests is wrong in my opinion. We should only watch for changes in the tests files and the files that are imported inside them, which can be achieved with configuration shown in the last URL.
Very important for hot reloading to work (at least in my case it was what made it work), you need to setup webpack-dev-middleware configuration in order to update the tests bundle everytime a change happens in some test file or the files being imported inside them. This is the config I'm using:
karma.config.js
{
...
webpackMiddleware: {
watchOptions: {
aggregateTimeout: 300,
poll: 1000, // customize depending on PC power
},
},
...
}
More info about it here.
I have same problem, as the TDD workflow that i use. After writing test then change the code the test doesn't re-run. Run test on every file change is possible.
As karma files have 3 options: Included, served, watched.
You can specify the bundle as pattern then tell karma to watch it
karma.config.js
files: [
// watch final file so when source change and it's final file, re run the test
{ pattern: './dist/js/*.wp.js', watched: true},
],
but when we use karma start no webpack active and watching. So use concurrently to run karma and webpack. Note that webpack should watch only the source code and karma should watch the bundle file.
Then we can add script property to package.json like so
package.json
"scripts": {
"test": "karma start karma.config.js",
"build": "webpack",
"dev": "concurrently \"webpack --progress --colors --watch\" \"karma start karma.config.js --colors\"",
},
Then run npm run dev to start coding
Well I've never heard of webpack up until now, but I know karma fairly well. I'm not 100% sure what you are asking here, so let me know if this isn't helpful at all. You can setup karma to do exactly what you want it to do (run tests on every file change).
There are two options that you must set in the karma.conf.js file: autoWatch: true and singleRun: false.
karma.conf.js
module.exports = function(config) {
config.set({
// set other options and stuff...
autoWatch: true,
singleRun: false
});
};
autoWatch set to true enables watching files and executing tests whenever any file changes. Setting singleRun to false means that you only need to execute karma start (or however you integrate it into webpack) once to run your tests, instead of having to enter the command every single time you make a change or want to run your suite; it just keeps karma running in the background.