flatiron/utile

other fs modules to merge in

coolaj86 opened this issue · 13 comments

I still think that the fs stuff deserves it's own moduel (because there's probably 10 common fs functions that aren't in core), but take a look and see what you think:

https://github.com/coolaj86/node-examples-js/tree/master/fs.extra

https://github.com/jprichardson/node-fs-extra

I really like the idea of keeping it clean by having one function per file.

@coolaj86 Thanks for following up from the other thread:

  1. We don't use coffeescript. It's an organizational decision based around talent acquisition. So https://github.com/jprichardson/node-fs-extra is right out. I believe this is meaningful b/c I have submitted patches to every module that utile takes as a dependency
  2. What should I be looking for in https://github.com/coolaj86/node-examples-js/tree/master/fs.extra? The aliasing you have setup seems a little more pragmatic than what we have here, but there doesn't seem to be any new implemenation(s). For example we have a copy implementation from https://github.com/avianflu/ncp. .move could be interesting, but I would like to see it as a single stand-alone module we could pull in as a dependency like mkdirp and ncp.

We can run a compiler on the coffeescript and get javascript.

I kinda like the idea of having all the files for the fs stuff in one place, but keeping the functions in separate files.

something like

fs-stuff/
    copy.js
    copy-recursive.js
    move.js
    unlink-recursive.js

so it's easy to maintain, but easy to find as well.

Also brought up this discussion here: jprichardson/node-fs-extra#2

@indexzero Understood regarding CoffeeScript. However, it's only a development dependency. How would you feel if only the tests were written in CoffeeScript?

@coolaj86

We can run a compiler on the coffeescript and get javascript.

Not quite sure what you mean here. I know .coffee compiles to .js. Are you saying you would hand-modify the compiled .coffee to be human readable .js?

@jprichardson We don't use CoffeeScript. Period. I'm sorry, but there is simply no negotiating on this point. It's not the additional dependency in the package.json (although it does annoy me when module authors do that): it is that if we were to make that call you (and only you) would be on the hook for maintaining them because it's not a core competency. While you may be comfortable with that, we are not.

We should probably establish a list of all new proposed FS methods so we can start stubbing them out and get tests in place.

@jprichardson, why don't you take that one? You had some ideas on what the name should be so that they follow NodeJS and posix convention?

@coolaj86 Regardless of the traction that utile has achieved, unfortunately, I think it's wrong approach. I believe in logical grouping of methods outside of Node core. I know, I know, one could state that all these methods are utility methods and hence belong in utile. But, I think that's a bit of a stretch for my tastes to include control flow, class, string, and file system methods. I prefer an extra file system library, and extra string library, etc. If some methods don't belong in such libraries, then maybe they should go in a utility extra like library.

I'm happy to work with the community on these libraries and I still subscribe to the points as stated here: jprichardson/node-fs-extra#2 (comment)

@Marak, I agree with @jprichardson on this point of organization.

Perhaps a better approach would to be to establish utile as a something more like a seal of approval.

fs = require('fs.utile')

or

fs = require('utile.fs')

such that each submodule contains related methods that fit well together, but not in the same repo.

And then to have a documentation site that is exactly like node's, but with utile modules.

In order to have the seal of approval the code has to follow certain guidelines (like strict mode, javascript, and a certain style of documentation (so that it can be easily included into the node-like documentation).

@jprichardson I agree with @Marak about the JavaScript core competency. CoffeeScript is cool and fun, but it's more overhead for those participating in the community.

CoffeeScript does have the merit of not requiring a person to be so vigilant and knowledgable to program well. It is a better language. There's just too much overhead for noobs and too much debate in the hard-core community.

@coolaj86 I think that's a great idea regarding your thoughts on organization. @Marak / @indexzero what are your thoughts?

Regarding CoffeeScript, I agree and have no problems ditching it in order to contribute to such a project.

@Marak @indexzero @jprichardson,

bump.

I'm ready to make a move on this. Shall we call it fs-extra, separate from utile, but close to its heart?

@coolaj86 Are you interested in bringing this effort under the flatiron umbrella? We'd love to have your contributions. If so, can we call it utile-fs?

That sounds great. If you create it, I'll fork it and merge in stuff from my repo, and @jprichardson's, convert the coffee to javascript and make the names of all the functions more terse.