I've just set up a create-react-app project with typescript. I've added eslint with npx eslint --init. When I run npx eslint src/ or npx eslint src I get an error:
Oops! Something went wrong! :(
ESLint: 8.18.0
No files matching the pattern "src" were found.
Please check for typing mistakes in the pattern.
However, if I use this command: npx eslint src/* then it works. This is fine, but some guides and stackoverflow comments (eg on here) I've seen show that the commands that don't work for me are working for seemingly everyone else. What am I doing wrong?
eslint.js
module.exports = {
env: {
browser: true,
es2021: true,
jest: true,
},
extends: ["plugin:react/recommended", "standard"],
parser: "#typescript-eslint/parser",
parserOptions: {
ecmaFeatures: {
jsx: true,
},
ecmaVersion: "latest",
sourceType: "module",
},
plugins: ["react", "#typescript-eslint"],
rules: {
semi: "off",
quotes: "off",
"space-before-function-paren": "off",
},
ignorePatterns: ["**/*.css", "**/*.svg"],
};
package.json:
"dependencies": {
"#testing-library/jest-dom": "^5.14.1",
"#testing-library/react": "^13.0.0",
"#testing-library/user-event": "^13.2.1",
"#types/jest": "^27.0.1",
"#types/node": "^16.7.13",
"#types/react": "^18.0.0",
"#types/react-dom": "^18.0.0",
"react": "^18.2.0",
"react-dom": "^18.2.0",
"react-scripts": "5.0.1",
"typescript": "^4.4.2",
"web-vitals": "^2.1.0"
},
"devDependencies": {
"#typescript-eslint/eslint-plugin": "^5.30.0",
"#typescript-eslint/parser": "^5.30.0",
"eslint": "^8.0.1",
"eslint-config-standard": "^17.0.0",
"eslint-plugin-import": "^2.25.2",
"eslint-plugin-n": "^15.0.0",
"eslint-plugin-promise": "^6.0.0",
"eslint-plugin-react": "^7.30.1"
},
Okay the comments I left were incorrect. This question left me reading about ESLint, how it works, and how the npm/npx commands differ.
So here is the deal
NOTE: "I use the syntax $(pwd) to refer to the current-working-directory, because it's not a pseudo representation of a path, but rather a command, wrapped as such, that it can be interpreted, and ran, by the BASH shell."
In the comments, I wrote about eslint resolving paths, and its inability to infer the meaning of the CLI passed argument src, as shown in this snippet:
/* COMMAND-1 */
$ eslint src
Thinking back on it, that was a really dumb comment to make, that I shouldn't have said. The reason it wasn't smart, is because, the way the path is resolved completely changes when you use the following:
/* COMMAND-2 */
$ npx eslint src
Looking at the two commands together, side by side, is helpful in the sense that it allows us to draw a side by side comparison, however, there really isn't much to compare, because of how different these two commands are.
So the first command, COMMAND-1, resolves src as if it were a path, however, COMMAND-2 executes an ESLint internal command, hence the "X" in npx, which is the same as executing...
npm exec or npm x
In other words, the following; npx eslint src can also be executed using npm x eslint src, or npm exec eslint src.
So, as stated above, **the argument src is not a system file-path, but rather, it's an internal ESLint command that offers a cute little CLI printout of your errors. ITS ACTUALLY PRETTY COOL
Initially the Command didn't work for me either
The problem I had, looks, like it was the same problem your having.
The solution is quite simple.
Update NPM to the latest version.
Update NPX to the latest version. (more on this below)
Update Node.js to the latest version
Update ESLint to the latest version
Update all of your proj's pkgs, then audit them with the fix command (more on this below).
So NPM comes with the NPX command embedded in it, and technically, npx is the npm command, just ran as npm x or npm exec, however; from the standpoint of your file-system, (in other words, looking at the commands from the context of /usr/bin/...) they are two different commands.
So I know alot about ubuntu because it was my OS for 7 years. About a year ago I switched to Fedora 36: Workstation and was glad I did. I made the change because of the issues associated with installing Node.js & NPM. Ubuntu makes it difficult. The reason I use Linux in the first place is because software runs in an environment that suited for running software, and not suited for protecting the proprietary licenses associated with the software. Anyways, long story made short... the best way for you to upgrade NPX (which means upgrading NPM, which means you need to upgrade Node.js), is to install the latest version of Node.js, go into the directory, and create symbolic links for npm, node, npx, in your /usr/bin directory and then upgrade eslint (globally) to version v8.18.0. You may also need to create a symbolic link for ESLint.
On a final note, just to point out somthing. You notice your ESLint version your package.json file is v8.18.0? and the version in the error you are getting is v8.1.0?
That is because your local & global eslint installs are different versions of eslint. You should try to always keep everything the same version.
Right now your system is trying to execute npx eslint src as if src is a path, but one everything is updated, you should have the software needed, for eslint & npm to know that its an ESLint command your trying to execute, not a path.
I think you should have this property in tsconfig.ts file :
"baseUrl": "."
I am writing a simple script to clone a project that is setup to use Vite w/all eslint and prettier config files already populated. I have looked on NPM site and googled but cant find a suitable answer. The repo has a package.json like so:
"dependencies": {
"vue": "^3.2.20"
},
"devDependencies": {
"#vitejs/plugin-vue": "^2.4",
"#vue/compiler-sfc": "^3.2.20",
"eslint": "^8.1.0",
"eslint-config-prettier": "^8.3.0",
"eslint-plugin-vue": "^7.20.0",
"prettier": "2.4.1",
"vite": "^2.6.4"
}
}
So my script does a clone
git clone https://github.com/mysite/vite-prototype.git %viteApp% && ECHO.
and then
CD %viteapp% && npm install
If I run this script 9 months from now I would like for the packages to all be the latest ones. Any ideas most welcome.
The answer depends on what you mean by "latest" ones. For example, your package.json contains "eslint": "^8.1.0". If you want to install the latest 8.x but not install 9.x or newer, then remove the node_modules directory along with any lock file or shrinkwrap file and then run npm install. On Unix-like operating systems, that would look like this:
rm -rf node_modules package-lock.json npm-shrinkwrap.json yarn.lock && npm install
If by latest ones you mean even ignoring semver major changes--so even if it is a breaking change going from (say) 8.x to 9.x or later--then first change the versions throughout your package.json to be *. So, for example, the ESLint entry would now be "eslint": "*". This is far more likely to result in incompatible dependencies breaking your app so be prepared to handle that. One limitation to this approach is that it will get you the version tagged latest on npm. If you want, say, the version tagged next or beta or whatever, you won't get those.
in my reactjs app, which has been created with creat-react-app, I've created these files
.env
.env.developmnet
.env.development.local
which contains REACT_APP_END_POINT=localhost:3001
the problem is when I run npm start the process.env.REACT_APP_END_POINT is undefined, but if I run the command like REACT_APP_END_POINT=localhost:3001 npm start, everything is fine.
here is the versions for related packages:
"react": "^16.13.1"
"react-scripts": "3.4.1"
Please make sure your .env place as the same level with src and 'package.json'
Create React App docs suggest forking react-scripts (instead of ejecting) if we have many similar projects. That's exactly my use case - I am trying to standardize the packages and structure that I always use in a React project. I would like to add these packages to the generated package.json file as opposed to the dependencies of react-scripts. For example, in the generated package.json file, the dependencies section should look like this:
"dependencies": {
"#material-ui/core": "^3.9.2",
"react": "^16.8.3",
"react-dom": "^16.8.3"
},
It appears that the only way to do this is to modify create-react-app itself because the code that generates package.json resides there.
I know that the CRA team recommends against modifiying create-react-app itself. So is there any other way to achieve what I am trying to do?
So I am trying to use react-redux with typescript. This is what my package.json looks like
"dependencies": {
"#types/react-dom": "15.5.0",
"#types/react": "15.0.4",
"#types/react-redux": "4.4.39",
"axios": "0.16.2",
"react": "15.0.0",
"react-dom": "15.0.0",
"redux": "3.6.0",
"react-redux": "5.0.6",
"redux-thunk": "2.1.0",
"office-ui-fabric-react": "1.0.0"
}
Now when I do yarn install. I see multiple react types get installed. Once for #types/React. One for #types/React-redux and #types/react-dom inside each of its own node_modules folder. And the version of the types these modules install internally are very different as I see in my yarn.lock file.
When I try to compile this, I get the errors like
error TS2304: Cannot find name 'DetailedHTMLFactory'.
Subsequent variable declarations must have the same type
The error disappears if I duplicate all the nested #types and just keep teh top level #types/react.
Whats a better way to do this, so that duplicate types issue doesn't appear ?
Since you are using yarn, the easiest direction might be to use resolutions in the package.json file to force specific versions of the typings, see https://github.com/yarnpkg/yarn/pull/4105
Other than that you would have to figure out which specific versions of these typings work with one another. Basically look at #types/react-dom dependency list and then include the same version of #types/react in your project.
You should try to remove your node_modules folder, run yarn cache clear and reinstall everything. There is an issue on the typescript repo about this behaviour ( I ran into it recently with one of my side projects ) that i'll try to find and link to this answer.
So I finally fixed this by excluding node_modules folder.
Put "node_modules" in the "exclude" section of tsconfig.json .