-
Notifications
You must be signed in to change notification settings - Fork 1
4 Design decisions
Gulp is a well-known package for setting up a development pipeline. We can create, overwrite or even compose tasks in a simple way. It's a very popular package with a big community and with many usable tasks. Once we've got gulp in our project, urbanjs-tools can be integrated seamlessly.
Yeoman is a great tool without doubt but with a different approach. It's going generate the template files for the project and helps the maintanance process of it.
The problem here is that the generated files contain the actual scripts and the configuration of the used tasks which is perfect as a boilerplate but not in this case. The gulpfile would contain hundreds of lines and basically it would be an automated copy&paste from projects to project.
A third party package has more benefits:
- the dependencies can be found in the packages.json of
urbanjs-toolsinstead of the project and it ensures by tests that the used versions work together - the packages can be updated by updating only one package instead of following the changes of the different packages
As a final thought we need to see that yeoman is another layer and the generators can use urbanjs-tools. These are not for the same purpose, these are not concurrency of each other.
Basically you've got two options with babel to add babel helpers & polyfills to the transpiled code base:
babel-runtimebabel-polyfill
You can check this for further information about these two.
Urbanjs-tools switched to babel-runtime because it does not have any effect on the globals and it results a cleaner solution this way. babel-polyfill has one extra behaviour, namely that only one instance can be used in the source. This hidden dependency of the package is something that should be avoided.
soon...