A Toolkit that supports building all kinds of applications in wix.

• Node.js v8.9.1 or above

$ npm install --save-dev yoshi

Configure package.json scripts,

The following is a only a sample usage:

{
"scripts": {
    "start": "yoshi start",
    "pretest": "yoshi lint && yoshi build",
    "test": "yoshi test",
    "build": ":",
    "release": "yoshi release" // only needed if you publish to npm
  }
}

Make sure your node version is above 8.9.1

// .nvmrc

8.9.1

The following sections describe the available tasks in yoshi. You can always use the --help flag for every task to see its usage.

The following are the default values for the CDN server's port, mount directory and whether to serve statics over https or regular http. You can change them in your package.json:

"yoshi": {
  "servers": {
    "cdn": {
      "port": 3200,
      "dir": "dist/statics",
      "ssl": false
    }
  }
}

This task will perform the following:

1. Compile using TypeScript (*.ts) or babel (*.js) files into dist/. In case you do not want to transpile server (node), you can remove .babelrc/tsconfig/package json's babel key. If you still need those (for transpiling client code), please use yoshi.runIndividualTranspiler.
2. Copy assets to dist folder (ejs/html/images...).
3. Add Webpack stats files to target/. Two files will be created: target/webpack-stats.prod.json and target/webpack-stats.dev.json for production and development builds respectively. These files can later be used for bundle analysis.

You can specify multiple entry points in your package.json file. This gives the ability build multiple bundles at once. More info about Webpack entries can be found here.

"yoshi": {
  "entry": {
    "a": "./a",
    "b": "./b",
    "c": ["./c", "./d"]
  }
}

Note: if you have multiple entries you should consider using the optimization.splitChunks

Note2: the decision whether to use TypeScript or babel is done by searching tsconfig.json inside the root directory.

By default, this task executes both unit test (using mocha as default) and e2e test using protractor. Default unit test glob is {test,app,src}/**/*.spec.+(js|ts). You can change this by adding the following to your package.json:

yoshi: {
  specs: {
    node: 'my-crazy-tests-glob-here'
  }
}

• Note that when specifying multiple flags, only the first one will be considered, so you can't compose test runners (for now).

• Mocha tests setup:

  You can add a test/mocha-setup.js file, with mocha tests specific setup. Mocha will require this file, if exists. Example for such test/mocha-setup.js:

  import 'babel-polyfill';
  import 'isomorphic-fetch';
  import sinonChai from 'sinon-chai';
  import chaiAsPromised from 'chai-as-promised';
  import chai from 'chai';
  
  chai.use(sinonChai);
  chai.use(chaiAsPromised);

• Karma tests setup:

  When running tests using Karma, make sure you have the right configurations in your package.json as described in yoshi.specs section. In addition, if you have a karma.conf.js file, the configurations will be merged with our built-in configurations.

• Jasmine tests setup:

  Specifying a custom glob for test files is possible by configuring package.json as described in yoshi.specs. The default glob matches .spec. files in all folders.
  If you wish to load helpers, import them all in a file placed at 'test/setup.js'.

• Jest test setup:

  You may specify a jest config object in your package.json, for example:

    "jest": {
      "testRegex": "/src/.*\\.spec\\.(ts|tsx)$"
    }

• How to debug tests

Executes TSLint or ESLint (depending on the type of the project) over all matched files. An '.eslintrc' / tslint.json file with proper configurations is required.

Bump package.json version and publish to npm using wnpm-release.

Configurations are meant to be inside package.json under yoshi section or by passing flags to common tasks.

By default, your required css will bundled to a separate app.css bundle. You can leave your css in main js bundle by adding the following to your package.json:

"yoshi": {
  "separateCss": false
}

Configure webpack's optimization.splitChunks option. It's an opt-in feature that creates a separate file (known as a chunk), consisting of common modules shared between multiple entry points.

Supports both false value (default), true and a configuration object:

"yoshi": {
  "splitChunks": true
  }

We use css modules as default. You can disable this option any time by adding the following to wix section inside your package.json:

"yoshi": {
  "cssModules": false
}

You also use the prod keyword to only separate css on CI and production, this is useful for speeding up HMR on local dev environments.

"yoshi": {
  "separateCss": "prod"
}

Disabling cssModules on a specific css file is possible by adding .global before file extention. For example:

./Counter.global.scss //no css modules for this file

Using css modules inside your component is easy:

import s from './Counter.scss';//import css/scss

<p className={s.mainColor}>{counterValue}</p>

Using css when css modules are turned off:

import './Counter.scss';//import css/scss

<p className="mainColor">{counterValue}</p>

Explanation is in cli/build section.

Explanation is in cli/start section.

Prevent bundling of certain imported packages and instead retrieve these external dependencies at runtime (as a script tags)

{
  "yoshi": {
    "externals": {
      "react": "React"
    }
  }
}

Specs globs are configurable. browser is for karma, node is for mocha and jasmine.

{
  "yoshi": {
    "specs": {
      "browser": "dist/custom/globs/**/*.spec.js",
      "node": "dist/custom/globs/**/*.spec.js"
    }
  }
}

For example:

{
  "yoshi": {
    "specs": {
      "browser": "dist/src/client/**/*.spec.js",
      "node": "dist/src/server/**/*.spec.js"
    }
  }
}

In case you don't want to transpile your server (node) code, and you still need .babelrc/tsconfig, you can add runIndividualTranspiler flag to skip server transpiling.

You can explicitly ask build process to transpile some node modules in case those modules do not contain transpiled code. Note that this is not a recommended workflow. It can be very error prone:

1. It might be for example that your app babel config and the node module babel config will be conflicting.
2. Any babel plugin that is used by your dependencies will need to be installed by your app as well.
3. You'll need to also add nested dependencies that need transpiling into array, which can be confusing.

Anyway, if you don't have a better alternative you can pass array with module names in this property.

If set, export the bundle as library. yoshi.exports is the name.

Use this if you are writing a library and want to publish it as single file. Library will be exported with UMD format.

Boolean | "auto" Set to false in order to disable hot module replacement. (defaults to true) "auto" is an experimental feature which provides zero configuration HMR for react. It will include react-hot-loader to the top of the entry file and will wrap React's root component in special Higher Order Component which enables hot module reload for react. Also it will call module.hot.accept on the project's entry file.

Allows to use the Webpack Performance Budget feature. The configuration object is the same as in webpack. For more info, you can read the webpack docs.

• How do I debug my application/tests?
• How to add external assets to my client part of the project?
• How to use HMR? And how to customize React project to use it?
• How to add and use babel-preset-yoshi?
• How do I setup Enzyme test environment?
• How to export ES modules along with commonjs?
• How to disable css modules in specific places
• How to I analyze my webpack bundle contents
• How do I separately bundle common logic for multiple entries?
• How to use SVG
• Moment.js locales are missing
• How do I add automatic AB tests to textual content?