Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Kickoff Builds #193

Open
ashleynolan opened this issue May 24, 2017 · 3 comments
Open

Kickoff Builds #193

ashleynolan opened this issue May 24, 2017 · 3 comments

Comments

@ashleynolan
Copy link
Contributor

Moving the build conversation out of the v9 conversation here.

@ashleynolan
Copy link
Contributor Author

ashleynolan commented May 24, 2017

@mrmartineau Just to address the last comment - I will already be maintaining a set of gulp build tasks here. If we could create the webpack tasks in a similar way then we’d have two different setups being maintained.

With respect to the maintenance anyway, most of the build tasks should change less frequently than the rest of the project. It tends to only be when we want to move away from a technology that a major change is required.

@mrmartineau
Copy link
Member

@ashleynolan the fozzie repo is still private btw. We could definitely create a installable setup, kind of like kickoff-scripts already does. Perhaps instead, we use a community effort like Neutrino to manage this sort of thing.

With Neutrino, you install presets, there are official and community packages; see a list of community packages here: https://neutrino.js.org/presets/community-presets.html

@ashleynolan
Copy link
Contributor Author

@mrmartineau Should be open sourced this week, but it’s on NPM currently. Basically it lets you pull in a set of gulp tasks and use those. So the logical thing would be that we could do the same with the webpack tasks – create a kickoff-build-webpack module that is installed and then changing this out for a different set of tasks is very simple.

Not sure how Neutrino works, but open to any ideas on how we could modularise these tasks. The goal with the one we’re building at JE is for this exact reason – so projects working with React/Angular/no framework can all have separate build tasks that can be shared across projects while also being very customisable to those projects.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants