Steal should come pre-packaged with meta and map configurations for popular packages.

[mjstahl]

Every time I start a new project running steal and I want to use Chai or Mocha (or many other popular packages that are escaping me right now) I go look up how to set up the meta and map properties in steal's configuration.

I believe packages that are used a lot (we can judge that by looking at projects that Bitovi is currently developing) we should include meta and map properties pre-configured.

[justinbmeyer]

@matthewp can one package be configured from another package?

@mjstahl instead of bundling it with steal, and having to support changes to these other packages (and possibly handling different versions) ((and having to change steal's version number if things break)) I think we should either:

• Create steal-chai, steal-mocha packages like the steal-qunit package.
• Support "configuration" packages. You could make the configuration in these packages.

[justinbmeyer]

Actually, there is a steal-mocha: https://github.com/stealjs/steal-mocha (no steal-chai)

[mjstahl]

I was trying to avoid the User having to think /at all/ about steal's configuration (which is probably not 100% achievable, but I am good with 80%-95%). By requiring them to install steal-mocha they would have to know why which I think would defeat the purpose. That is unless steal imports steal-mocha.

I think a default-configurations repo would be good assuming steal itself imported and used it, and we didn't require the user to npm install it and configure it in some way.

I look at this as more of a quality of life issue, and in many cases steal looks like magic (until it doesn't and you don't know why), so /any/ way we can continue making it appear to be magical (removing as much configuration as possible) the better.

[chasenlehara]

I think the opposite would be better: make things less magical so it’s easier to understand and support in the future.

I think a page in the docs that explains how to set up popular packages (at specific versions) would be really useful.

[matthewp]

So what if we had a steal-popular-packages npm package that a dev just had to install that then autoconfigured? That would avoid the needing to include that stuff in steal but also make it super easy to use. Would that be an 85% solution?

[mjstahl]

I think that is a good compromise.

[matthewp]

Proposal

tldr; Provide a new package that has preconfigurations for a variety of popular npm packages.

This was discussed on a recent live stream.

Problem

As stated in this issue, certain packages always need configuration, like jQuery widgets in Bootstrap, or those that need to use a global build like Chai. Having to remember to configure these in each of your projects can be tedious.

Solution

Create a new package, perhaps steal-preconfigured that includes configurations for a variety of popular npm packages. Users can contribute to this project by adding their own configurations.

Secondarily, improve the documentation around popular packages on stealjs.com. In particular, point to existing Steal packages that handle the integration, such as steal-qunit for QUnit, steal-socket.io for Socket.IO, etc.

[eben-roux]

Is it not perhaps another option to have steal-tools provide a command line interface to perform the configuration for you?

steal-tools -configure jquery steal-tools -configure bootstrap

These configuration could be in some well-defined json "repository" file of sorts so to extend would be a rather simple affair.

Perhaps even a separate steal-tools-configure cli may be an option.