Is it possible to mark a project dependency as deprecated without removing it from the project.
So other developers don't use it in future
I have a project that was built on Material-UI V4 and have recently added Mui-V5 with the intention that all new work is built on V5. I'd like developers to see an IDE warning when they import components from the old dependency.
One thought I had is to use patch-package to modify Mui-V4 and set it as deprecated in package.json but this warning only shows on npm install.
Related
I've developed with React for a long time but I've only recently tried my hand at publishing packages.
A dependency of the package I'm working on causes issues if there are conflicting React installations between the package and the project it's being installed into. (The package is react-query)
How do I handle this situation?
Ideally I'd like the two versions to be the same as React 17.x and React 18.x have weird type changes which causes issues when being used together. But I'm honestly completely lost.
Googling doesn't seem to bring up anything I can use.
You should specify react as a peer dependency in your lib package.json file:
"peerDependencies": {
"react": ">= 17"
}
When encountering a peer dependency, npm will check the dependencies of the project that is using your lib:
If these include react matching the version requirements, then nothing else needs to be done
If a suitable version of react was not found, then npm will install the latest matching version
Behavior can be different with older versions of npm and only a warning will be printed in the console during npm install.
I installed eslint in my react project to fix all the eslint errors. I fixed all the errors, however, I can't npm start the project. When I do that, I get this error, and some steps to uninstall all the eslint dependencies. I want to run the project with eslint dependencies.
Please let me know how to do this?
Error Message:
There might be a problem with the project dependency tree. It is
likely not a bug in Create React App, but something you need to fix
locally.
The react-scripts package provided by Create React App requires a
dependency:
"eslint": "^7.11.0"
Don't try to install it manually: your package manager does it
automatically. However, a different version of eslint was detected
higher up in the tree:
My guess would be that you installed eslint#v8 and since create-react-app doesn't support it yet (reference) it causes this error.
Downgrading to eslint v7 should fix it.
Create react app already comes bundled with eslint and by installing it in the project dependencies, you are in effect try to load in conflicting versions, you shouldn't need eslint inside of your own package.json.
HOWEVER
If you want to override eslint and start customising your react install you are more than welcome to eject (npm run eject), but bear in mind that ejecting your application will mean you will need to maintain dependencies going forwards.
You can read more about ejecting here - https://create-react-app.dev/docs/available-scripts/
I'm working on a React project that does not yet use a linter as part of the project. I want to avoid checking in eslint as part of the project so I'm considering installing eslint globally on my laptop. Here's the npm page for eslint:
https://www.npmjs.com/package/eslint-plugin-react
Per the documentation on this page:
"Install ESLint either locally or globally. (Note that locally, per project, is strongly preferred)"
Are there any downsides to installing eslint globally? As a matter of practice, a local project install is better practice. But I wasn't sure if there were any practical downsides that I should be aware of for installing ESLint globally.
I'm building a UI lib for my organization, I'm using react with material-ui as a peer dependency in the package.json of the lib. I wanted to add storybook to have a playground for the components I'm building but the problem is: My lib is built upon Material-ui, which as I said above, is a peer dependecy and Storybook doesn't find material-ui because it's a peer dependency of the projetct.
How should I deal with that?
It makes sense Storybook is not finding material-ui because it is supposed to be installed in the host project that is going to use my ui-lib. Installing material as a dependency is not the case since it would break whoever implements the lib. I tried to see something about the Lerna project, but I'm not very familiar with that.
I'm open to hear any ideas :)
I managed to find a workaround to this issue and wanted to share with the community. It's pretty silly but it works perfectly for my case.
I added #material-ui both as dev dependency and peer dependency to my package.json and removed it from dev dependecies on my Docker file when I added it to the aws pipeline. So on while coding we have #material-ui but on prod environment it is not there.
That solved it for me :)
I could also just do "npm uninstall #material-ui" before "npm publish"
Just starting (again) with material UI and react. There are two packages material-ui and #material-ui, which is the best starting point (latest) as of 2019-07 timeframe?
I think it is npm install #material-ui/core based on ... https://material-ui.com/getting-started/installation/. The GIT repo is at https://github.com/mui-org/material-ui
Simple question, hopefully simple answer.
Other questions I looked at:
Use Create-React-App with Material UI - This answer says to use npm install --save material-ui but because it is 2 years old, I think it may be out of date.
Difference between Material-Ui and Material-Ui-Next
How to install Material-UI Docs WITHOUT installing material-ui?
#material-ui/core is the correct one to use for v4. For v5, the equivalent package is #mui/material.
If you go to https://www.npmjs.com/package/material-ui, you'll see that material-ui is deprecated. The last stable version in the material-ui package was 0.20.2. For the 1.0 release it moved to #material-ui/core and for the stable release of v5 it moved to #mui/material.
The #material-ui scope (for v4) is used for the following packages that are all managed within the monorepo you referenced (https://github.com/mui-org/material-ui/tree/v4.12.3/packages):
#material-ui/core
#material-ui/icons
#material-ui/styles
#material-ui/system
#material-ui/lab
#material-ui/utils
#material-ui/types
#material-ui/docs
#material-ui/codemod
Similarly, the #mui scope (for v5) is used for the similar set of packages supported for v5 (https://github.com/mui-org/material-ui/tree/master/packages):
#mui/material
This is the equivalent of #material-ui/core
#mui/core
This is the NOT the equivalent of #material-ui/core. #mui/core is a new package for unstyled (no Material-Design CSS applied) versions of the components.
#mui/icons-material
#mui/styles
This is for supporting the withStyles and makeStyles JSS-backed styling APIs and is not recommended for use in new projects.
#mui/system
#mui/lab
#mui/utils
#mui/types
#mui/docs
#mui/codemod
The # scope indicates package ownership
The main advantage of scopes I've seen so far is that each scope is controlled by npm account of an organization / user, much like GitHub usernames / organization names.
This way, it makes it easy to determine if the package you are looking at belongs to an organization you trust, or if it is a third party tool.
For example, if you see:
#material-ui
then you know that it comes from the material-ui team and can be trusted.
On the other hand, the same could not be said about:
material-ui
For more https://docs.npmjs.com/about-scopes