I have a question about using angular-cli. I had used it, but I had trouble with override webpack conf, sass files, assets conf. In other hand I have nice boilerplate with karma tests sass and other confs, which is enough for most projects. Which solution is better? angular-cli or spent some time and get own custom boilerplate?
It is a personal answer and every developer would have its own.
Mine is:
Angular-cli should be up to date with the latest things in Angular 2 while with your own build/compile process may not.
There is no problem in using your own set, but you can be out of date without even known and end missing some good features that angular-cli may have.
But you should use what you think is better for you and your project. Any option will work. Like I said, is more a personal opinion then a absolute truth.
Related
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.
I want to write a node cli application and im wondering how i should structure the application. Im fairly new to node and im a confused with all the design patterns used when building such a application.
I want to be able to call the application from the command line, but also use it as a node module for better testing.
Currently i have one file with lots of functions that get called directly from the cli, but i feel this is rather difficult to maintain.
Is there any good writing on how to do such things? i looked at rimraf but it confused me even more. Thanks for your time
I don't know if there is a "right" way to do it but I can tell you how I have dealt with a problem similar to yours. I wanted to create a CLI and a visual studio code plugin so people would be able to use the functionality both from VSC and from the CLI (for those that don't use VSC), so the approach I took was to put all the logic in its own package and then create two other packages that included the first one, one for CLI and one VSC plugin that required the "logic" package.
In the CLI package you would only have code strictly related to command handling and then the real meat happens in the logic package. In my case the VSC plugin package had very few lines of code, just configuration and the calls to the needed functions.
Then regarding the structure of the code some recommendations:
expose only what is strictly necessary
isolate your code in different files/classes based on common functionality (and go to point 1)
test your code
lint your code
But those are common sense and language independent recommendations.
There's no one "standard" way to structure Node.js apps, however you will notice that many authors follow similar patterns. Instead of having one file containing all code, it should be split out into modules, grouped by function. Have a look at this repo on Github, it has some very good suggestions about Node.js best practice https://github.com/i0natan/nodebestpractices#1-project-structure-practices.
A couple more pointers I would add: Ensure you're logging any errors, consider using something like Winston.js for this purpose. Also have some mechanism in place to restart the service if a critical error occurs, e.g. Forever.js.
Ensure likewise you're unit testing, there are some good test frameworks, Jasmine, Mocha, Cucumber.js.
Since I know now, what "angular compiler" actually means, this would be my next question.
I read here about the positive and negative points of ahead of time compiling. To me, it boils down to this:
Use AOT for deployments
Use JIT for development
The only valid reason (imho) for JIT is, that it runs way faster (which is nice for the development process). Is there any other reason?
AOT has so many HUGE advantages over JIT, that I wonder why JIT is even an option for for a deployment.
Well, There are many difference and some of them are pointed out by you very well. It also dependent what kind of environment you are in and your requirement.
I have been using angular since angular-2.beta.17 when angular cli was not existed and we have to take the help of many build system and run environment to run the project in anywhere.
Systemjs building and running:
In some situation where multiple project and frameworks run together, you can not make a AOT build and bootstrap your code into the SPA and run. In system js environement you have to load the scripts one by one and they bootstrap it.
You must have seen this kind of build and loading script in many online tools like codepen, plunker, etc. I think they all uses systemjs loading
There are many other like commonjs loader, babel build system, webpack build system. But now angular cli is a bullet proof tool with internally use web pack and amber cli to handle everything you want.
Ahead of Time compilation and JIT debugging
As the name suggest AOT do a tree shaking and include everything which is really used in your code and throw away unused codes and compact the code size which can be loaded very fast. But by doing that it looses debugging control and don't give you a nice error message if in case in production you want to see what is wrong.
Same time JIT can point to the line number in typescript file which have the error and make your life super easy to debug while running in dev mode through angular cli.
You can get lot more in angular compiler and there are many tools and games available as well.
one of my favorite is ngrev
I'm trying to create angular ui-component, and use it in other angular applications.
I met many problem with angular-cli and decided to get rid it from my project, since it is not ready for building library.
I tried to use webpack, but had a problem with building d.ts bundle(I used dts-bundle, but it can't build bundle with all imports well).
When I created d.ts bundle manually, I realized that project which use webpack don't work correctly with bundly already built by webpack (a lot of errors with third party, module resolution, polyfills).
When I build project with typescript, it worked well, by angular templated (app.component.html), which I don't want to include in my package.
The best way, I think, manage to use something like angular-template-loader
with typescribt compiler, but I don't know how.
May be there is better approach for it, but I read a lot of topics and have't figured it yet.
Thank you.
I'm an Angular 1 dev currently looking to get to grips with Angular 2, however with the changes and rewrites so far it's a bit of a quagmire.
All of the full ecosystems I've found are from late 2015, the testing ngdocs are outdated and there doesn't seem to be a clear up to date scaffold for Angular 2.
Has anyone come across a recommended setup or been able to set something up themselves? Something like Yeo is not strictly necessary but I'd need Typescript compilation and linting, live reload for development, unit testing, minification, SASS compilation and dependency management.
I would default to Gulp, Jasmine & Karma for the build system and tests but ideally I want to start off learning the best suited technologies from the start.
Bonus points for Webstorm integration :)
I'd check out the Angular-CLI project. It's an official CLI toolchain with testing and build built in. It's still a bit unstable with the changeover to webpack, but if you're working with RC software that's to be expected.
While waiting for angular-cli to become a bit more mature, I've been using the Fountain Webapp generator. Long term, I'll probably move to angular-cli.