v0.10 refactor marty-constants and marty-utils

[dariocravero]

First steps towards refactoring and extracting packages for #253. Put marty-constants and marty-utils into their own package. Removed deprecated stuff in constants. Will expand on the code later on, have to run but wanted to share it :) Thoughts?

[jhollingworth]

ah annoying, I just did the same thing this afternoon!

[jhollingworth]

I'm going to publish where i'm at tomorrow morning

[jhollingworth]

I'm going to close this if its ok

[dariocravero]

Sure. After a first pass at the refactoring and the registering mechanism presented I think there's lots of room for simplification - need to play more with it but I think we might not even need the whole registering process at all. From my PR I'd rescue things like the playground, everything on root instead of lib and the build/test process inside package.json as scripts rather than bash scripts orchestrated from a Makefile but I understand if you like that approach better. Thoughts?

[jhollingworth]

• playground is cool although maybe its worth having it within the marty repo?
• What are the motivations for having everything at the root? Reason for keeping everything in lib is i've found it makes a lot of build processes much easier to have all application code in one folder. Also, as of v0.10 you will no longer be able to do thinks like require('marty/when'), you will have to do require('marty-store').when. This is thanks to npm only allowing you to switch the root entry point (e.g. main: "dist/node/main.js"
• I'm a big fan of make, it's on most peoples computers already so you don't have to install anything and gives you the flexibility to use whatever's the best language for the job (e.g. if you want to execute js you run node foo.js, if you want to run a bash script you run sh foo.sh.

[jhollingworth]

Somewhat in the middle about co-locating __tests__, it seems its the way everyone is going with them. maybe I should move with the times?

[dariocravero]

• I found playground useful no matter how small the project is; if modules are isolated you should be able to play around with them on their own;
• as for having everything with root, I think it's a more natural approach because, even though you can specify an entry point, you would have to use lib in your path if you want to require some file inside the structure or explicitly import the files on that entry point. Here's an example to illustrate my point, if you have:

lib/index.js
lib/file.js
lib/module/file.js

and want to require/import say, lib/module/file.js I need to either have it exported in lib/index.js and import the main lib as you said above or require('my-lib/lib/module/file') which adds lib in between because of the way node_modules are required. If it's not prefixed by lib I can simply require('my-lib/module/file') which is the file I was after.

Of course you can also have a build process that puts the files in the correct path inside that dist/node folder but unless I'm missing something on why dist/node is being generated (other than it being ES5 compatible-code), I think that having babel properly setup (through the use of a .babelrc file which came out in 5.0.0) should ease the conversion process and allow us to build for ES6 without having to compile that down to dist/node.

• the example you brought up on main.js remind me that I meant to ask why didn't you name it index.js to follow module require conventions?
• good point on make :)
• I think tests make sense with the source they run and it definitely makes it easier to remember to write them (I know this shouldn't be an excuse, still...) if they are in place too.

[oliverwoodings]

I personally prefer unit tests next to the source (but you probably already know this :+1: )