Split project into core and cli packages

[gabejohnson]

From https://github.com/sweet-js/sweet.js/pull/660#issuecomment-290271808

I think babel is a good place to look for inspiration.

I'm thinking sweet-core is for compiling macros, sweet-helpers is for writing macros and sweet-cli is for...well it's sjs.

(out of scope): I'm also thinking we could add something like babel-node. A REPL would be great for playing around with ideas.

[gabejohnson]

Should we alias sjs as sweet too? I sometimes find myself typing sweet. /cc @disnet

[disnet]

No, to avoid confusion there should only be one command. Shell aliases are there for your personal typos 😜

[disnet]

I just created a sweet-cli repo to start this process. The most obvious thing to do as you mentioned is to have both sweet-core and sweet-cli packages to separate the cli and the API. But what should we do about the existing sweet.js package? We could either:

• npm deprecate it and let it die
• not introduce sweet-core and just remove the cli stuff from sweet.js
• have it be a shell package that essentially re-exports sweet-cli and sweet-core

I suspect that npm deprecate is the right option.

[gabejohnson]

What about a mix of 1 and 2. We could:

1. npm deprecate
2. have sweet.js be a shell until v4
3. update docs to remove references to sweet.js
4. update the README to suggest and point to sweet-cli
5. let sweet.js die after v4 is released

I understand that this would be a bit more work, but anything to avoid alienating the current users (v3 was just released last week after all).

I don't feel strongly about it though.

[disnet]

That's a really good idea. We'll do that then.

[disnet]

Doh! Turns out sweet-cli has already been taken.

Since we need our own namespace I've just created the @sweet-js npm org so we can publish under that scope.

[gabejohnson]

Fixed in #689