npm package.json config variables used for version numbers - reactjs

I have 3 React-related packages in my package.json, and the version numbers must be in sync. I know with Maven, you can define variables in the POM file to re-use and keep version numbers in sync across different packages.
I want to do the same thing with my npm package.json, like so:
...
"config": {
"react_version": "^15.4.1"
},
"dependencies": {
"react": "$npm_package_config_react_version",
"react-addons-test-utils": "$npm_package_config_react_version",
"react-dom": "$npm_package_config_react_version"
}
...
It seems that config variables set in the package.json file can only be used inside your script commands.
Is there a way to solve this problem at the moment? Will something like this be included in a future version of npm?

I've been wrestling with this too. The issue for me has been that I want to use different npm tags in different environments ('latest' for dev, 'prod' for prod). The solution I came up with is to use an environment variable for the tag. I set up something along the following in package.json. Since I'm using 'latest' everywhere except for production servers, I avoid the problem of inadvertently changing the git repo:
"scripts": {
"start": "perl -pi -e \"s#\\\"package_name\\\".*#\\\"package_name\\\": \\\"$TAG_VAR\\\",#\" package.json && node app.js"
},
"dependencies": {
"package_name": "latest",
"other_package": "^1.0.0"
}

Related

React.version stating older version than is in package.json

I am attempting to use the React devtools to produce a flamegraph profile of my app, but I was greeted with the message:
After checking my package.json version number, I saw it was set to "^16.4.1".
I performed an update to both the React and React-Dom versions: npm i --save react#16.5 && npm i --save react-dom#16.5, which updated both versions in the package json to "^16.5.2". I also cleared my node_modules and deleted the package.lock before doing an npm install once again.
However, when I run both my local instance of the app and push changes to my staging environment, it is outputting 16.14.0 as the version number that I have specified to log out in at the start of the App.jsx...
This is puzzling also as the logged out a version earlier than my package.json originally stated...
Is there somewhere that I am missing to update versions that could be causing this?
I have done a global search in my project for 16.14 to see if there is anything and it seems that some of my dependencies have mentioned this version, but I wouldn't think that it would be an issue?
package.lock
------------
"dependencies": {
...
"react": {
"version": "16.14.0",
...
},
...
"react-dom": {
"version": "16.14.0",
...
},
...
}
I don't understand what is going wrong here?

"No files matching the pattern "src" were found." when using "npx eslint src" or "npx eslint src/"

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": "."

Can you clone a git repo and update all packages to latest version

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.

Showing error in yarn start command says This package doesn't seem to be present in your lockfile; try to make an install to update your resolutions

The error shown when yarn start command is given
Error details:
Internal Error: confusion#workspace:.: This package doesn't seem to be present in your lockfile; try to make an install to update your resolutions
at J.getCandidates (C:\Users\risha\Desktop\Front-End Web Development with React\.yarn\releases\yarn-berry.js:2:276872)
at i.getCandidates (C:\Users\risha\Desktop\Front-End Web Development with React\.yarn\releases\yarn-berry.js:2:266282)
at C:\Users\risha\Desktop\Front-End Web Development with React\.yarn\releases\yarn-berry.js:2:286432 at C:\Users\risha\Desktop\Front-End Web Development with React\.yarn\releases\yarn-berry.js:57:349928
at new Promise (<anonymous>)
at e.exports (C:\Users\risha\Desktop\Front-End Web Development with React\.yarn\releases\yarn-berry.js:57:349910)
at o (C:\Users\risha\Desktop\Front-End Web Development with React\.yarn\releases\yarn-berry.js:57:349611)
at C:\Users\risha\Desktop\Front-End Web Development with React\.yarn\releases\yarn-berry.js:57:349684
at C:\Users\risha\Desktop\Front-End Web Development with React\.yarn\releases\yarn-berry.js:57:349727
at new Promise (<anonymous>)
My package.json file is
{
"name": "confusion",
"version": "0.1.0",
"private": true,
"dependencies": {
"react": "^16.13.1",
"react-dom": "^16.13.1",
"react-scripts": "3.4.1"
}
}
I have tried adding
"scripts":{
"start":"react-scripts start"
}
But no change in the error.
Cross-posting from this question:
The problem in here seems to be an existing yarn.lock file inside of one of the workspaces. Deleting it solves the problem.
More info:
Example: 3 workspaces: 2 create-react-app (app, home) and one shared component: (components)
Inside the component folder a lingering yarn.lock file exists. Remove it.
Also check that:
All your workspaces have "private:true" in each of their package.json (same level as name, private, source).
Check that you have added your workspaces inside a "workspaces" key in the main package.json
When you're executing yarn workspaces myworkspace myworkspace matches the name of your workspace in its package.json. In my case, the name of the workspace inside the components folder is called #schon/components, so I need to address it as yarn worksapces #schon/components instead.
It means a certain package is not installed, and you need to install it.
Try running yarn install to install the required packages.
If this does not work, try deleting the node_modules folder and run yarn install again.
If it fails, delete both node_modules folder and yarn.lock file and run yarn install.
try to remove node_modules by installing this package globally
yarn add global rimraf
then remove the node
the -> rimraf node_moules
then remove the yarn.lock the install it by yarn

Forking react-scripts to add custom dependencies

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?

Resources