As part of a major refactoring of my Node.js app (going DDD), I'm looking for a library that through inspecting code is able to visualize module dependencies (by means of 'requiring' them) between different node-modules.
Visualizing in Table-format is fine, I don't need fancy graphs.
Any Node libraries out there?
If you may accept also some fancy graphs: http://hughsk.github.com/colony/
I do not know if this exists, but I found the following by quick search:
http://toolbox.no.de/packages/subdeps
http://toolbox.no.de/packages/fast-detective
Maybe subdeps is not exactly what you want right now, but I think you could use these projects to make that project yourself?
See also https://github.com/pahen/madge
Create graphs from your CommonJS, AMD or ES6 module dependencies. Could also be useful for finding circular dependencies in your code. Tested on Node.js and RequireJS projects. Dependencies are calculated using static code analysis.
I just published my node-dependency-visualizer, which is a small module, that creates a digraph from your node dependencies. Paired with graphviz/dot you can create a dependency graph as svg (or other image format) which you can include with your documentation, embed in your Readme.md, ...
However, it does not check, whether the dependencies are actually needed in code - not sure, whether the OP meant that with "requiring". Of course this question is old, but this tool might be helpful for others, too.
Sample image (Angluar cli):
Related
I am creating my first open source project, and I am making some plugins for it. These plugins will be published as npm packages, and they will have identical dependencies.
My question is, what I the best way to deliver them and avoid code repetition? I know I can use something like Rollup.js to pack all dependencies used by that module in the final distribution js file, but if the user is using multiple modules, the inlined dependencies will be repeated and make the file bloat.
I know end user can use a bundler to remove those repeated codes, but is there anything more I can do to reduce the size of my distribution js files?
Please tell me which option is better ?
Option 1: All these methods will be in Track module
getTrendingTracks
getMyFavoriteTracks
likeTrack
unlikeTrack
getMyPlayedTracks
playTrack
getArtistTracks
Option 2: These methods will be in separate modules
Track module
getTrendingTracks
Like module
getMyFavoriteTracks
likeTrack
unlikeTrack
ListeningHistory module
getMyPlayedTracks
playTrack
Artist module
getArtistTracks
It depends on the size and the future development of the application.
If the project is small and you don't expect to have a lot of new functionality option 1 is a good choice. It will keep all things close to one another and you will be able to find and modify them easily.
For projects with a lot of functionality and longer lifespans option 2 is better. This way you will be able to create smaller and more cohesive modules. These modules will depend on other modules, so you can create a module dependency map. This way you can manage the dependencies in your application better so you don't end up with spaghetti code.
When you want to add new functionality you will have to do one of several things:
Add a new module. This is the coolest thing in options 2. You just add a completely new thing to get new functionality.
Extend an already existing module. Having smaller modules makes this a lot easier.
Extend a small number of modules. Having smaller cohesive modules makes this a lot easier too
I highly recommend taking a look at Unreal Engine. It has a very good modular architecture. It has a huge codebase, so in order for it to be manageable, they split the Engine into modules. You can check it here
Theos lists it supports
Third party frameworks can be placed inside $THEOS/lib, and utilised with instance_EXTRA_FRAMEWORKS. (kirb)
But I am not sure how to make it work or trouble shooting, can someone explain what's this for, and how to use it? If I already build a binary, and the binary needs some frameworks, how to do it?
I tried to follow the samples like putting frameworks under $THEOS/lib and add the flag, but when it runs, for example I am adding AWSCore.framework and AWSS3.framework, it reports library not loaded, image not found
I need to understand how the framework is added into my binary, and what's the run path etc. and how to debug where goes off. Thank you. Does the binary already contains the framework, or I should copy it to somewhere?
Let's say I have a project where I want to use Lo-Dash and jQuery, but I don't need all of the features.
Sure, both these projects have build tools so I can compile exactly the versions I need to save valuable bandwidth and parsing time, but I think it's quite uncomfortable and ugly to install both of them locally, generate my versions and then check them it into my repository.
Much rather I'd like to integrate their grunt process into my own and create custom builds on the go, which would be much more maintainable.
The Lo-Dash team offers this functionality with a dedicated cli and even wraps it with a grunt task. That's very nice indeed, but I want a generic solution for this problem, as it shouldn't be necessary to have every package author replicate this.
I tried to achieve this somehow with grunt-shell hackery, but as far as I know it's not possible to devDependencies more than one level deep, which makes it impossible even more ugly to execute the required grunt tasks.
So what's your take on this, or should I just move this over to the 0.5.0 discussion of grunt?
What you ask assumes that the package has:
A dependency on Grunt to build a distribution; most popular libraries have this, but some of the less common ones may still use shell scripts or the npm run command for general minification/compression.
Some way of generating a custom build in the first place with a dedicated tool like Modernizr or Lo-Dash has.
You could perhaps substitute number 2 with a generic one that parses both your source code and the library code and uses code coverage to eliminate unnecessary functions from the library. This is already being developed (see goldmine), however I can't make any claims about how good that is because I haven't used it.
Also, I'm not sure how that would work in a AMD context where there are a lot of interconnected dependencies; ideally you'd be able to run the r.js optimiser and get an almond build for production, and then filter that for unnecessary functions (most likely Istanbul, would then have to make sure that the filtered script passed all your unit/integration tests). Not sure how that would end up looking but it'd be pretty cool if that could happen. :-)
However, there is a task especially for running Grunt tasks from 'sub-gruntfiles' that you might like to have a look at: grunt-subgrunt.
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.