I only use a small subset of the org.apache.commons.math3... class tree and would like to package only what I need.
Is there any way to get a dependency tree that may help the process of repackaging manually?
The current download of 3.6.1 is 2.2MB and I'd like to reduce that size to ideally only the classes in the closure of what I use.
Related
Right now I'm going through my application, changing instances of this pattern:
import {Grid, Row, Col} from 'react-bootstrap'
into:
import {Grid, Row, Col} from '../react-bootstrap'
where react-bootstrap.js is a simple file at the root of my project, with a selective import of the ES6 modules I need from that NPM package:
import Grid from 'react-bootstrap/es/Grid'
import Col from 'react-bootstrap/es/Col'
import Row from 'react-bootstrap/es/Row'
export {Grid, Col, Row}
Doing this for a number of packages, I was able to reduce my bundle file size by more than 50%.
Is there a WebPack module or plugin that can do it automatically for any package?
If this transformation (that is, only including in the bundle what is explicitly imported, instead of the entire library) was applied recursively to the entire package tree, I bet we would see a dramatic size difference.
Edit: as Swivel points out, this is known as Tree Shaking and is supposed to be performed automatically by Webpack 3+ with UglifyJSPlugin, which is included in the production configuration from react-scripts that I'm using.
I'm not sure if this is a bug in either of those projects, but I'm seeing big size gains by doing selective imports manually, which shouldn't be the case if Tree Shaking was being performed.
I used to search for this and found this article. It is very helpful. I hope it works for you.
Whatever tool that would be would be equivalent to implementing tree shaking, and it would need to be integrated into your bundler. So, no.
For the record, dead code elimination is not the same thing as tree shaking. Tree shaking is breaking unused dependencies between modules. Dead code elimination is within a single module. Uglify.js only knows about one module at a time, so it cannot do tree shaking: it just does dead code elimination. So the fact that you are using the UglifyJSPlugin is irrelevant to whether or not your build environment has tree shaking.
There is a large project on Golang which divided into many packages. I want to visualize the relationship between its entities to better understand the structure of the project. The first thing that comes to mind - the dependency graph classes. How to build it?
PS:
And I want find all unused method's / structures
The tool closest to what you search (but without the diagram feature though) would be go oracle
It can be embedded in:
Atom with atom.io go-oracle package
SublimeText with the waigani/GoOracle plugin
I also like to use test cases in order to compute a code coverage, which also helps to pinpoint unused methods.
I consistently implement an ITreeNode interface on all my tree structures. It would be excellent to have a vizualizer available when debugging that would display a tree structure in a treeview. Apart from writing my own from scratch, is there any open source vizualizer out there that could be adapted to recognize my ITreeNode interface?
Take a look at the JsonViewer at http://jsonviewer.codeplex.com/ which provides a tree visualizer for Json String.
I have modified the same for my project use to visualize my objects as tree and you can try the same.
I'm creating a OpenCL high-level haskell library. Where's the best path in haskell tree for put it? I think it should be outside of Graphics subtree but I dont know where to put it.
It's based on Jeff Heard OpenCLRaw (He put that one on System.OpenCL.Raw.V10).
Update:
I just started a repository, http://github.com/zhensydow/opencl
Update: Options that I propose (and fomr answers)
System.GPU.OpenCL
Control.Parallel.OpenCL
Foreign.OpenCL
How about putting it in Control.Parallel? The haskell-mpi package uses Control.Parallel.MPI, and there's also the commonly used Control.Parallel.Strategies so it seems like an appropriate prefix.
Shameless plug: I wrote a small script for fun to extract the hierarchical module tree from all packages on Hackage. It might be useful for seeing what hierarchical modules other packages use. I'll clean up the code and release it some time in the future. For now, here's the Hackage tree as of May 2011.
I'd like to use #Grape in my groovy program but my program consists of several files. The examples on the Groovy Grape page all seem to assume that your script will consist of one file. How can I do this? Should I just add it to one of the files and expect that the imports will work from the others? If so, then is it common to place all the #Grape calls in one file with no other code? Do I need to add the Grape call to all files that will import the package? Do I need to download the JAR and create a Gradle file, which I was getting away without at this point?
the grape engine and the #grab annotation were created as part of core groovy with single file scripts in mind, to allow a chunk of text to easily become a fully functional program.
for larger applications, gradle is an awesome build tool with lots of useful features.
but yes, you can manage all the application dependencies just with grape.
whether you annotate every file or a single one does not matter, just make sure the #grab annotated file is read before you try to use the external class.
annotating the main class is probably better as you will easily lose track of library versions if you have the annotations scattered.
and yes, you should consider gradle for any application with more than a dozen files or anything you might want to reuse elsewhere as a library.
In my opinion, it depends how your program is to be run...
If your program is to be run as a collection of standalone scripts, then I'd probably stick the #Grab required for each script at the top of each of them.
If your program is more of a standard style program with a single point of entry, then I'd go for using a build tool like Gradle (as you say), as you get a lot of easy wins by using it.
Firstly, it makes it easy to define your dependencies (and build a single large jar containing all of them)
Secondly, Gradle makes it really easy to start writing tests, include code coverage plugins, or useful tools like codenarc to suggest possible fixes or improvements to your code. These all become invaluable not only for improving your code (or knowing your code works), but also when refactoring your code, you know you've not broken anything that used to work.