I have an angular application I haven't touched in a while. I haven't made any changes since the last time it was working. Now I need to modify a few things. But the application won't serve locally so I can't make the changes. I don't understand what's wrong.
The npm install worked just fine and I don't have any code errors preventing it from running. I get the following error message when trying ng serve, but it seem extremely unhelpful. Any ideas?
Unfortunately without an exact reproduction of your project this will be really hard to pin point, but looking at what is given in the screen shot and prior experience with similar issues, I think this could be an issue with your package.json. Newer versions of node and npm look for the carets symbol (^) in both your package.json and the installed modules' package.json. When found, it will install newer versions of the package without error. Then when you go to run the project, the typings will break and Angular will refuse to compile and you get errors like these.
I would recommend removing all carets in older Angular projects to prevent this from happening as it is common occurence even when upgrading from more modern versions (I had this happen to me when upgrading from Angular 13 to Angular 14). However, with Angular 1.7/AngularJS not being supported anymore, I would recommend that you look into upgrading or rewriting the project in a modern version of Angular or another modern framework that fits the projects needs.
I ran depcheck to find the packages not being used in a legacy project and removed them but now when I run the project I get errors about "cannot find module". I did a global search for the one of those unfound modules and there is no require, no import, no mention at all of that library anywhere in this project. If you git clone this project and do a case-insensitive grep for the library name you will get zero results.
Here's my 1 question, phrased in 4 different ways to make it 100% clear what am I asking:
What is the mechanism at work here?
How can any dependency in any JS project ever be necessary if nothing uses it?
How are you supposed to know if a dependency is safe to remove if you can't determine that based on whether the code uses it?
What hidden mechanism in npm/JS am I not understanding?
Yarn includes an optional "Plug'n'Play" feature which moves node_modules out of the project directory. In doing so it creates a .pnp.js file with references to various dependency paths on the hard drive.
The file is auto-generated, is several thousand lines long, and appears to reference paths specific to the machine that ran yarn install.
Is .pnp.js meant to be commited with the rest of the code? I can't seem to find any information about this despite the file appearing to be useless to commit. What is conisdered best practice and why?
I found this comment by Arcanis (the lead maintainer of Yarn) on an issue asking about what to include in a .gitignore. It may answer your question:
.yarn/plugins and .yarn/releases contain the Yarn releases used in the current repository (as defined by yarn set version). You will want to keep them versioned (this prevents potential issues if, say, two engineers use different Yarn versions with different features).
.yarn/unplugged should likely always be ignored, since it may contain native builds
.yarn/build-state.yml should likely be ignored as well, as it contains the build infos
If for some reason you version unplugged, it may make sense to keep build-state as well
.yarn/cache may be ignored, but you'll need to run yarn install to regenerate it
Versioning it unlocks what we call Zero-Installs - it's optional, though
.pnp.js (and potentially .pnp.data.json) are in the same boat as the cache. Add it to your repository if you keep your cache in your repository, and ignore it otherwise.
yarn.lock should always be stored within your repository (even if you develop a library)
So to summarize:
If you're using Zero-Installs:
.yarn/unplugged
.yarn/build-state.yml
If you're not using Zero-Installs:
.yarn/*
!.yarn/releases
!.yarn/plugins
.pnp.*
As one of the commenters noted, the official .gitignore recommendations are here, along with excellent commentary. The only critique I have is in the way they showed it there, I think they should have combined the common ways into one, and then separated the special cases for zero-install vs not. Here then is how I have it. But again, note that article, as some of these (e.g. .yarn/sdk) are optionally added or not.
# ------- yarn -------
# see excellent notes at: https://yarnpkg.com/getting-started/qa#which-files-should-be-gitignored
# Also: `yarn.lock` and `.yarnrc.yml` (or it's older counterpart .yarnrc) "should always be stored in your repo"
.yarn/*
!.yarn/patches
!.yarn/plugins
!.yarn/releases
!.yarn/sdks
!.yarn/versions
## --> ADD if using zero-install, otherwise do NOT:
#!.yarn/cache
## --> ELSE ADD if NOT using yarn's zero-install:
.pnp.*
# ------- end yarn -------
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.
Can anyone explain the versioning behind TypeScript #types
https://github.com/DefinitelyTyped/DefinitelyTyped
For example:
I assumed that if I was using mocha#3.4.2 then I would been to install #types/mocha#3.4.2.
Howerver, this version does not exist. It get worse. for example, react-addons-test-utils#15.6.0 and #types/react-addons-test-utils#0.14.19. What does that mean? What version is this targeting?
How, can I make sure that I'm installing the correct version of the Types for the library version?
Unfortionaly it may be just a "doing it wrong" matter. Generally, It's a good practice to give the #types version the same version of the library itself. But regarding the patch part of the semantic version, it will differ in most cases.
Possible causes why versions may differ:
There are no updates in types so the library has been patched for example but the #types one hasn't.
#types library is not well maintained.
#types library has many bugs and patches.
Nice to mention:
You can definitely contribute to any #types library and help to keep it well versioned.