trailsjs / trailpack-webpack

:package: Webpack Trailpack.
MIT License
11 stars 1 forks source link

Splitting into implementation-specific trailpacks #4

Open weyj4 opened 8 years ago

weyj4 commented 8 years ago

While working on trailpack-react, it occurred to me that webpack configs are specific to the implementation they're a part of. That is, maybe it makes more sense to have a trailpack-react, trailpack-angular, etc. with the corresponding webpack configs for those frontends, than to simply have a shell webpack that the user will pretty much have to write themselves anyway.

For reference, here's a first pass at trailpack-react: trailpack-react

jaumard commented 8 years ago

Make sense... Also it can be nice if trailpack-react trailpack-angular... can include multiple config files. Because I don't use webpack, I prefer gulp (https://github.com/YannBertrand/trailpack-gulp) so if trailpack can also include a gulp config file it can be nice :).

Where I asking myself about this is what if I want my webpack or gulp to do custom task. With the config file include under the trailpack it can be hard to customize it. It will be better to include it also under archetype and use yo trails:trailpack trailpack-react to install it, like this all archetype files are copied on current project and can by edit by the user.

nogtini commented 8 years ago

Agree about the config file approach, though I think we should talk about this being a "universal trailpack approach", as having different trailpacks that are primed to take config files in different ways would be a poor design decision.

Maybe each Trailpack can take a "Trailguide" config file that is well documented about how to prime any trailpack for any specific implementation, instead of having the user simply adapt on the fly.

weyj4 commented 8 years ago

I understand some users will want, for instance, gulp instead of webpack. However, I don't think we want to have both gulp and webpack getting set up when you install trailpack-react.

Short of having trailpack-react-webpack and trailpack-react-gulp, etc, I'm not sure what to do.

Joey, are you suggesting, instead of having an archetype/config/webpack.js or archetype/config/{gulp whatever}, that we'd just have docs telling how to set up a webpack/gulp build? In that case this trailpack is basically just wrapper for dependencies and documentation. Let me know what y'all think.

I do think it makes sense to put the webpack config in archetypes/config, like @jaumard said.

nogtini commented 8 years ago

I think this has potential on a larger scale. Instead of having the user hook up base packs that are exposed to the trails ecosystem (trailpack-react -> trailpack-webpack) and then configure the trailpack, we could have the idea of a "Trailmap" that gets plugged into the Trailpack and can act as a recommended boilerplate.

For instance, I love our webpack config. If we had a "Langa Trailmap" we could use to prime the Trailpack then the user could be building product in much the same way we are.

weyj4 commented 8 years ago

I'm going to break the webpack config back out of trailpack-react and put it back here. Ideally trailpack-webpack or trailpack-gulp should interface the same way with trailpack-react.

As a result, our starting webpack config will be very sparse. But like Joey said, we could have a nice Trailmap telling users exactly how, for instance, to install and configure webpack plugins for a react app, etc.

scott-wyatt commented 8 years ago

Old discussion, but now that i've been using webpack for some time with trails, the biggest thing that I am realizing is that webpack is a compiler and it shouldn't be in a trailpack at all. Grunt and Gulp really shouldn't be either. It makes a lot of sense to make distros of trails apps that are precompiled and then start a node app vs a node app doing the compiling – especially when considering app clusters. I have this scratching feeling that this is a legacy concept from sails eg. sails does everything when it shouldn't.