I'm creating an app using Parcel and #material-ui/styles. My app has the #material-ui/styles dependency. I'm also importing my own npm package that I store locally. This package has also the #material-ui/styles dependency but it's peer dependency. I would assume that this package would use the #material-ui/styles package from my app but there are two different instances of the same package which causes the It looks like there are several instances of "#material-ui/styles" initialized in this application. This may cause theme propagation issues, broken class names and makes your application bigger without a good reason. error.
I was describing it here: https://github.com/mui-org/material-ui/issues/15745 but no one is even trying to help me. It's probably not related directly with the package I'm using but the way how bundlers work. I don't know why Parcel is bundling this package two times instead of just doing it once.
The same problem appears when I try to use Webpack. I always thought that peer dependency will work the way I described.
Here is a reproduction repository: https://github.com/lukejagodzinski/mui-styles-reproduction
Does anyone know how to solve this problem?
I ran into the same issue and this helped me: https://github.com/parcel-bundler/parcel/issues/1838#issuecomment-492369750
That basically will remove the duplicated dependency on build time.
Also be aware that you are using TS, so there's one additional complexity on this issue.
Related
I know that there are already a lot of posts concerning the distinction between dependency and devDependency but I didn't find any that explain it for the case of svelte so lets open this one here.
In most of the svelte package like svelte-material-ui or svelte-routing, the installation guide tell to install the package as a dependency. However since svelte will compile this package during the build time, the new library that will use it doesn't need to install this svelte package. So I don't see why it has to be a dependency.
Maybe this question is opinion based but would be nice to have at least a small idea of what to use.
I believe this is personal opinion. If you're not distributing your code as an NPM package, the distinction should be minimal. See, for example, this related discussion.
In my experience with web projects, it's helpful to distinguish between dependencies that are used for building/testing (devDependencies) vs. those that are "used at runtime" (dependencies). You're right that, with Svelte, none of the literal code is used at runtime, but then everything would be a devDependency, so you don't get a useful separation.
The NPM documentation says that the distinction should be production vs. development/testing.
In SvelteKit (the next version of Sapper) there is one major difference between dependency and devDependency: any module used in a (server-side) endpoint must be a dependency. If not, the project may not work when deployed on a serverless platform, although it will work locally.
Otherwise, I prefer to keep everything as a devDependency. I think it makes sense because Svelte is a compiler, and the packages are only needed at compile-time. However, I don't think it would hurt to just put everything as a dependency.
I am studying React.js., and I have started by setting the project folders to try some codes. But, some terms are confusing me as a beginner. One of them is "dependency." When I search for it, the result is only related to dependency injection stuff, but what is the "dependency" itself?
A dependency is some third-party code that your application depends on. Just like a child depends on its parent, your application depends on other people's code. A piece of code becomes a true dependency when your own application cannot function without it.
If you want to look at the dependencies you're using, you can find them in the package.json file under the dependencies key.
Well, dependencies are those things that you need to install and import for doing specific things, for example, if you want to add routing(moving from one page to another which changes your URL) in your react project then you need to install react-router-dom dependency by doing
npm install react-router-dom
A dependency is just a package that your project uses.
Very few javascript projects are entirely self-contained. When your project needs code from other projects in order to do its thing, those other projects are "dependencies"; your project depends on them to run.
When you install third-party packages via npm install <package>, you're adding a dependency.
Your project's package.json file includes a list of your project's dependencies.
Let's say I just recently installed react-native-gifted-chat from npm, and I realized there is another package inside it, how do I access uuid package in that package?
this is inside my node_module folder:
Regularly we just do import ... from 'react-native-gifted-chat', to access package but how to access uuid package inside react-native-gifted-chat without installing uuid package?
The question is: Why do you want this?
I believe that the correct approach should be to depend on uuid directly, if you actually depend on it.
There is no guarantee that future versions of react-native-gifted-chat will depend on uuid, or depend on a version that has the same interface you're expecting.
Also, I believe that npm makes some effort to deduplicate the same versions of packages depended on by multiple things, so you shouldn't concern yourself overly about disk space.
well, I think the best way is to install the wanted packages as new separate packages with npm, because maybe in the future, the devs of react-native-gifted-chat may stop depending on that package, and you will get errors that may drive you crazy before realizing the mistake you have done, so you better install uuid as a new dependency in your project so you will never have to worry about it being removed from react-native-gifted-chat.
Hope i was clear, thanks
In order to refactor a client-side project, i'm looking for a safe way to find (and delete) unused code.
What tools do you use to find unused/dead code in large react projects? Our product has been in development for some years, and it is getting very hard to manually detect code that is no longer in use. We do however try to delete as much unused code as possible.
Suggestions for general strategies/techniques (other than specific tools) are also appreciated.
Thank you
Solution:
For node projects, run the following command in your project root:
npx unimported
If you're using flow type annotations, you need to add the --flow flag:
npx unimported --flow
Source & docs: https://github.com/smeijer/unimported
Outcome:
Background
Just like the other answers, I've tried a lot of different libraries but never had real success.
I needed to find entire files that aren't being used. Not just functions or variables. For that, I already have my linter.
I've tried deadfile, unrequired, trucker, but all without success.
After searching for over a year, there was one thing left to do. Write something myself.
unimported starts at your entry point, and follows all your import/require statements. All code files that exist in your source folder, that aren't imported, are being reported.
Note, at this moment it only scans for source files. Not for images or other assets. As those are often "imported" in other ways (through tags or via css).
Also, it will have false positives. For example; sometimes we write scripts that are meant to simplify our development process, such as build steps. Those aren't directly imported.
Also, sometimes we install peer dependencies and our code doesn't directly import those. Those will be reported.
But for me, unimported is already very useful. I've removed a dozen of files from my projects. So it's definitely worth a shot.
If you have any troubles with it, please let me know. Trough github issues, or contact me on twitter: https://twitter.com/meijer_s
Solution for Webpack: UnusedWebpackPlugin
I work on a big front-end React project (1100+ js files) and stumbled upon the same problem: how to find out which files are unused anymore?
I've tested the next tools so far:
findead
deadfile
unrequired
None of them really worked. One of the reason is that we use "not standard" imports. In additional to the regular relative paths in our imports we also use paths resolved by the webpack resolve feature which basically allows us to use neat import 'pages/something' rather than cumbersome import '../../../pages/something'.
UnusedWebpackPlugin
So here is the solution I've finally come across thanks to Liam O'Boyle (elyobo) #GitHub:
https://github.com/MatthieuLemoine/unused-webpack-plugin
It's a webpack plugin so it's gonna work only if your bundler is webpack.
I personaly find it good that you don't need to run it separately but instead it's built into your building process throwing warnings when something is not ok.
Our research topic: https://github.com/spencermountain/unrequired/issues/6
Libraries such as unrequired and deadcode only support legacy code.
In order to find the unused assets, to remove manually, you can use deadfile
library:https://m-izadmehr.github.io/deadfile/
Out of box support for ES5, ES6, React, Vue, ESM, CommonJs.
It supports import/require and even dynamic import.
It can simply find unused files, in any JS project.
Without any config, it supports ES6, React, JSX, and Vue files:
First of all, very good question, in large project coders usually try many lines of code test and at the end of result, hard to find the unused code.
There is two possible that must be work for you - i usually do whenever i need to remove and reduce the unused code into my project.
1st way WebStorm IDE:
If you're using the web-storm IDE for JS development or React JS / React Native or Vue js etc it's tell us and indicate us alote of mention with different color or red warning as unused code inside the editor
but it's not works in your particular scenario there is another way to remove the unused code .
2nd Way unrequired Library: (JSX is not supported)
The second way to remove the unused code inside the project is unrequired library you can visit here : unrequired github
another library called depcheck under NPM & github here
Just follow their appropriate method - how to use them you will fix this unused issue easily
Hopefully that helps you
I think the easiest solution for a create-react-app bootstrapped application is to use ESLint. Tried using various webpack plugins, but ran into out of memory issues with each plugin.
Use the no-unused-modules which is now a part of eslint-plugin-import.
After setting up eslint, installing eslint-plugin-import, add the following to the rules:
"rules: {
...otherRules,
"import/no-unused-modules": [1, {"unusedExports": true}]
}
My approach is an intensive use of ESlint and make it run both on IDE ad before every push.
It points out unused variables, methods, imports and so on.
Webpack (which has too nice plugins for dead code detection) take care about avoiding to bundle unimported code.
findead
With findead you can find all unused components in your project. Just install and run:
Install
npm i -g findead
Usage
findead /path/to/search
This question recalls me that react by default removes the deadcode from the src when you run the build command.
Notes:
you need to run build command only when you want to ship your app to production.
The order I add packages on Meteor makes any difference in the result ? Lets say I use bootstrap 3 and accounts ui with bootstrap 3, if I add the latter first or vice versa would work the same way ?
In Meteor the package order that you add them in does not matter.
There is a module in meteor called linker that analyses each packages dependencies to ensure that the dependencies load first.
For example: If bootstrap-3 is a dependency of accounts-ui-bootstrap-3 then even if bootstrap-3 was added after, it would be loaded first.
There isn't currently a way to test for or access an optional dependency from within a package. You can test for it's existence by testing if Package['author:package'] is defined. The problem is the load order. I got around it temporarily by editing the packages file in .meteor and moving the optional dependency package higher up in the list. I don't think it's a good long term fix though. This should be a Meteor feature suggestion, if it's not already.
Each package has a package.json file that lists what other packages it requires. This practice ensures that packages load in a proper order. Read these files to troubleshoot load-order issues.