Project organization

[asalant]

Don't you think it would be clearer/cleaner to have the coffee source in src/ and the compiled JavaScript in lib/? It seems like a standard convention to have the runtime code in lib/.

I've even seen some folks publish to npm without the src/ and test/ dirs and only lib/. I'm not proposing that - simply that src/ and lib/ would be more common/standard organizational approaches.

[alexgorbatchev]

Did a quick check on garbanzo node_modules, out of 105 top level modules, 62 have lib folder inside. It feels like a convention, but it's not very strongly followed. I would be more in favor of this if there were more files and root folder felt too busy, but with just two files, moving them into their respective folders wouldn't reduce number of files in the root folder.

Thoughts?

[asalant]

I still prefer it as it sets up for future file additions. It also makes it clear when looking at the project as a 3rd party what is going on. I actually was confused at first b/c I wasn't sure what the executable file was - there is a .js and .coffee file in the root. src/ and /lib/ makes it clear(er) what is going on. It's also a convention we have adopted in our other modules that compile coffee to js so would be consistent for our npm modules. Check out fibrous and teacup for examples.

[bobzoller]

+1 fwiw

On Wed, Nov 13, 2013 at 9:16 AM, Alon Salant notifications@github.comwrote:

I still prefer it as it sets up for future file additions. It also makes it clear when looking at the project as a 3rd party what is going on. I actually was confused at first b/c I wasn't sure what the executable file was - there is a .js and .coffee file in the root. src/ and /lib/ makes it clear(er) what is going on. It's also a convention we have adopted in our other modules that compile coffee to js so would be consistent for our npm modules. Check out fibrous and teacup for examples.

— Reply to this email directly or view it on GitHubhttps://github.com/goodeggs/grunt-mongo-migrations/issues/1#issuecomment-28413929 .

[alexgorbatchev]

Will do... There's just one problem, grunt expects tasks to be in the tasks folder.

[asalant]

Right, so then a different convention is needed or is it overkill?

src/ lib/ tasks/

compiles to

lib/ tasks/

I've learned from the past (Java) that keeping source separate from the compiled target is usually the better way to go for a number of reasons so I'm biased toward that.

[alexgorbatchev]

Sounds good.

[hurrymaplelad]

Grunt ships with coffee. If the task source is coffee, no need to package js files. Example.

Ideally the grunt task is just an api adapter around some other lib, and that lib should be packaged as js for portability.