Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

other fs modules to merge in #11

Open
coolaj86 opened this issue May 23, 2012 · 13 comments
Open

other fs modules to merge in #11

coolaj86 opened this issue May 23, 2012 · 13 comments

Comments

@coolaj86
Copy link

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.

@indexzero
Copy link
Member

@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.

@coolaj86
Copy link
Author

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

@jprichardson
Copy link

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

@indexzero
Copy link
Member

@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?

@indexzero
Copy link
Member

@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.

@Marak
Copy link
Contributor

Marak commented May 25, 2012

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

@coolaj86
Copy link
Author

@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?

@jprichardson
Copy link

@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)

@coolaj86
Copy link
Author

coolaj86 commented Jun 2, 2012

@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.

@jprichardson
Copy link

@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.

@coolaj86
Copy link
Author

@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?

@indexzero
Copy link
Member

@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?

@coolaj86
Copy link
Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants