Modularize steal-tools

[wclr]

I would suggest steal-tools to become more lightweight by removing traceour, transpile dependencies, I would even consider removing deps from clean-css and uglify, all this maybe not needed in custom transpile workflows.

All this stuff maybe included in donejs by default, but steal should be as lightweight and modular as it can be.

[justinbmeyer]

We shouldn't remove the ability for steal to do a production ready build without additional work. People, in general, want the ability to do the basics without hassle. That includes minification and the transpiration necessary for a working build.

Sent from my iPhone

On Apr 15, 2016, at 6:45 AM, Alex notifications@github.com wrote:

I would suggest steal-tools to become more lightweight by removing traceour transpile, I would even consider removing deps from clean-css and uglify dependencies, which maybe not needed in custom transpile workflows.

All this stuff maybe included in donejs by default, but steal should be as lightweight and modular as it can be.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub

[matthewp]

We have streams now for the purpose of customizing your build. You can omit the transpile step and do it yourself, you can omit the minify step. I also wish this stuff was split up into their own packages and steal-tools would just be the package that "brought it all together" but I don't know when I'll have time to do all the work necessary to do that splitting up.

[wclr]

Some people do not like exessive dependencies and bloated stuff. Esp when then take additional time to install (this is not such a big problem) but there is more serious one: different problems with flat NPM modules encourage problems with different versions you have to have babel6 and babel5 which you not need etc.

I think there is need to consider allowing more modular approach, maybe steal-tools may remain a bundle but there should be ability to compose some kind of system you need from steal parts.

@matthewp Yes I know about streams it is quite convenient thing. But now I'm talking about less dependencies and more modular approach. It is kind of obvious to me.

[justinbmeyer]

I'm confused. Transpile is another project, so is uglify. What would we need to split out?

Sent from my iPhone

On Apr 15, 2016, at 7:12 AM, Matthew Phillips notifications@github.com wrote:

We have streams now for the purpose of customizing your build. You can omit the transpile step and do it yourself, you can omit the minify step. I also wish this stuff was split up into their own packages and steal-tools would just be the package that "brought it all together" but I don't know when I'll have time to do all the work necessary to do that splitting up.

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub

[justinbmeyer]

Unless I'm missing something, modules that aren't useful out of the core project shouldn't be brought out.

Transpile makes sense because someone else could use it in theory.

Bringing things out otherwise doesn't seem to be worth the extra maintenance cost.

Sent from my iPhone

On Apr 15, 2016, at 7:12 AM, Matthew Phillips notifications@github.com wrote:

We have streams now for the purpose of customizing your build. You can omit the transpile step and do it yourself, you can omit the minify step. I also wish this stuff was split up into their own packages and steal-tools would just be the package that "brought it all together" but I don't know when I'll have time to do all the work necessary to do that splitting up.

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub

[justinbmeyer]

Those dependencies are all necessary to do the bare minimum ... A minified build.

I don't know what you mean by:

different problems with flat NPM modules encourage problems with different versions you have to have babel6 and babel5 which you not need etc.

Can you elaborate?

Sent from my iPhone

On Apr 15, 2016, at 7:32 AM, Alex notifications@github.com wrote:

Some people do not like exessive dependencies and bloated stuff. Esp when then take additional time to install (this is not such a big problem) but there is more serious one: different problems with flat NPM modules encourage problems with different versions you have to have babel6 and babel5 which you not need etc.

I think there is need to consider allowing more modular approach, maybe steal-tools may remain a bundle but there should be ability to compose some kind of system you need from steal parts.

@matthewp Yes I know about streams it is quite convenient thing. But now I'm talking about less dependencies and more modular approach.

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub

[wclr]

Transpile makes sense because someone else could use it in theory.

Well someone in "in theory" could use scss, or typescript, coffee,flow or whatever, but you don't have it right out of the box. Why include something at all? More over babel5 is actually becoming more and more obsolete as it do not support latest features and plugins etc.

Can you elaborate?

This is a problem of exessive deps and bloated stuff, exessive deps are not correct in theory (though in theory they should not mess with work). In practice the can be not visible until yet not polished NPM3 glitches somewhere on server while deploy because of huge amount of deps.

[matthewp]

I agree with @whitecolor here, having a very large project comes with some tradeoffs. If you are using all of steal-tools features it's very convenient and you have simple APIs for the common use cases. The downside is that the wealth of features makes it difficult to understand the individual parts. Part of this is a documentation problem, but I think all big projects have this problem.

If you wanted to do your own minifying (because you want to use closure) you could omit the minify stream and insert your own. But since streams were added after-the-fact their API isn't great. We pass around a BuildResult object to each stream and each stream modifies it. To do your own minification I think you would have to do something like minify(buildResult.bundles[0].nodes[0].activeSource).

Having separate projects forces you to make well defined APIs.

Unless I'm missing something, modules that aren't useful out of the core project shouldn't be brought out.

Definitely, lib/trace.js is probably not useful out of the core project, but lib/graph/make_graph_with_bundles.js is, I made a project that displays your dependency graph using it.

It's often hard to predict what will be useful and what will not be, that's why I tend to think in terms of "is this a different thing".

[wclr]

Definitely, lib/trace.js is probably not useful out of the core project, but lib/graph/make_graph_with_bundles.js is, I made a project that displays your dependency graph using it.

Right such things should be separated and be building blocks with strictly defined API.

[wclr]

Isn't it released yet?

[matthewp]

Not yet.

[wclr]

are we there yet?

[matthewp]

No need to ask every week, contributions welcome.

[wclr]

hm, sorry that is actually another issue that I was bothering about. 😕

[matthewp]

Replaced by #1035