spinjs - the best build tool - is the one that don't need build rules
Installation
npm install -g spinjsMotivation
spinjswas created to free the developer from build rules writing for JavaScript projects as much as possible. Its difference from many other build tools with similair goals is thatspinjsis not tied to specific framework and does not attempt to lock you out from generated config.spinjsdoes its best to provide you with very mature build setup from the minimal information provided by you about your tech stack and lets you further customize every aspect of build setup when needed.
Basic Usage
The basic spinjs usage is simple: you describe the stack used in your application in the property spin of package.json:
{
"spin": "webpack:babel:apollo:react-native:ios"
}and you are all set.
You can then execute
spin watchto launch your project in webpack watch mode for development. After making changes to your code, they will be
automatically reloaded from disk using Webpack Hot Module Replacement.
spin buildwill build your project for production environment.
spin test "src/**/*.spec.js"will run tests located in .spec.js files via Mocha Webpack.
To see generated Webpack config add -v option to any of the above commands, e.g.:
spin -v watchwill launch project in development mode and will dump generated Webpack config in a terminal.
Supported technologies stack
At the moment spinjs supports the following technologies, that can be specified inside stack property:
| Technology | Description |
|---|---|
| webpack | Webpack |
| babel | Transpile code from the ECMAScript 6 to ECMAScript 5 |
| ts | Transpile code from TypeScript to ECMAScript 5 |
| vue | Vue.js |
| i18next | Loader to generate resources for i18next |
| angular | Angular 4 |
| react | React |
| react-native | React Native with Expo |
| react-hot-loader | Use React Hot Loader during development |
| styled-components | Styled Components |
| css | CSS stylesheets |
| sass | SCSS stylesheets transpiled to CSS |
| less | LESS stylesheets transpiled to CSS |
| apollo | Apollo GraphQL |
| server | The code is targeted to run under Node.js |
| web | The code is targeted to run in Web Browser |
| ios | The code is targeted to run on iOS device |
| android | The code is targeted to run on Android device |
Concepts
spinjs configures and launches multiple builders in parallel to build the project. If stack for the project is specified
in spin property of package.json, then only one builder is launched. To specify multiple builders the following
configuration should be used:
{
"spin": {
"builders": {
"backend": {
"stack": "webpack:babel:apollo:react:styled-components:sass:server"
},
"frontend": {
"stack": "webpack:babel:apollo:react:styled-components:sass:web"
},
"mobile": {
"stack": "webpack:babel:apollo:react-native:styled-components:sass:ios"
}
}
}
}The 'spinjs' configuration can be specified in .spinrc.json instead of package.json, it should contain the value of
spin property in this case. The object with config can be also exported from .spinrc.js
Each builder has a name and a stack property at minimum. Builder properties recognized by spinjs:
| Builder Option | Description |
|---|---|
| stack | an array or semicolon separated string with list of stack features for the builder |
| plugins | Additional spinjs plugins module names |
| entry | path to entry source file for this builder (src/{platform}/index.{js,jsx,ts,tsx} by default) |
| enabled | whether this builder is enabled, true by default |
| roles | what are the roles of the builder, allowed values: build, watch, test, ["build", "watch"] by default |
| defines | assignments that will be available at compile time to all generated code |
| backendUrl | URL to a REST/GraphQL API of the application endpoint(http://localhost:8080 by default) - deprecated use defines and waitOn instead |
| waitOn | URL in wait-on npm package format to await for before emitting compiled code. This is useful for example to force front-end wait until back-end will be compiled and started first in dev mode |
| webpackDevPort | the local port used for Webpack Dev Server process to host web frontend files |
| buildDir | Output directory for built code |
| backendBuildDir | Output directory for code targeted to run under Node.js (deprecated, use buildDir instead) |
| frontendBuildDir | Output directory for code targeted to run in Web Browser and on mobile devices (deprecated, use buildDir instead) |
| dllBuildDir | Output directory for Webpack DLL files used to speed up incremental builds |
| backendUrl | Same as corresponding builder option |
| stack | Same as corresponding builder option, but prepended to each builder stack |
| ssr | Use server side rendering for the application (makes requiring web assets inside server code possible) |
| webpackDll | Utilize Webpack DLLs to speed up incremental builds (default true) |
| sourceMap | Generate source maps for output code (default true) |
| cache | One of true, false, 'auto', 'auto' enables Babel and other caching only during development, true enables caching for production builds too, false disables caching (default: 'auto') |
| frontendRefreshOnBackendChange | Trigger web frontend refresh when backend code changes |
| persistGraphQL | Generate and use Apollo persistent GraphQL queries |
| devProxy | Proxy all unknown requests from front-end running on Webpack during development to back-end |
| writeStats | Write stats.json to disk, default: false |
| nodeDebugger | To enable or disable node debugger, default: true |
| {toolName}Config | Additional options for webpack, loaders or other tools. The {toolName} should be the name of the loader or tool and the value is the additional config options for the loader. Possible names for the tools are: webpackConfig, babelConfig, cssConfig, sassConfig, graphqlTagConfig, etc |
Common builder options can be put into options property, from there they will be copied into each builder. stack property inside options will be prepended to each builder stack.
Builder can also have builder-specific options, depending on its stack, recognized by spinjs plugins.
Each spinjs plugin tries to handle subset of technologies in the builder stack to configure build tools
usually used for this stack the best way. After configuration of the builder it gets executed in the mode
that specified in spin command line, i.e. watch, build, test, etc.
There are several built-in plugins supplied with spinjs. External plugins can be specified inside
options -> plugins property.
Webpack, Babel and other tool-specific config merging
spinjs generates configs for various tools based on the stack specified, but sometimes you want to tweak generated configs. For this purpose you can provide webpackConfig, babelConfig, etc keys to each builder or into options if you want tweaking happen for each builder in config.
The values provided in these keys will be merged with config generated by spinjs with webpack-merge. You should check the result of this merging by running spinjs with -v option to show resulting configs, example:
npx spin -v watch
Though webpack-merge uses smart strategy to merge generated configs and the configs provided by you, but it is not smart enough in many cases and you need to configure merge strategy too, to get desirable results. For this purpose you should specify merge field
inside webpackConfig, babelConfig etc, with strategy used by webpack-merge.
Example:
const config = {
...,
options: {
babelConfig:
{
merge: { presets: 'replace' },
presets: [
["babel-preset-env", {modules: 'commonjs'}],
"react",
"stage-0"
],
}
}
}
See webpack-merge strategies documentation here
Current working directory
When reading .spinrc.js configs spinjs does so recursively in all the child directories. When config in each such directory is being read or builder get executed, process current working directory is set to point to this same directory. This
scheme of operation should be compatible to all 3rd party tools.
Community support
- Gitter channel - questions, answers, general discussions
- GitHub issues - submit issues, send feature requests
Commercial support
SysGears team provides advanced support for commercial partners. A commercial partner will have a premium access to our team whether this is to help you with your code based on this project or related technologies used in it. Contact us using Skype or via email: info@sysgears.com
Contributors
Thanks goes to these wonderful people (emoji key):
 Victor Vlasenko 💻 🔧 📖 |
 Ujjwal 💻 🔧 📖 |
 cdmbase 💻 |
|---|
This project follows the all-contributors specification. Contributions of any kind welcome!
License
Copyright © 2017 SysGears INC. This source code is licensed under the MIT license.