**TL;DR**
These changes affect workflow with yarn. To prevent embark's `prepare` script
from running undesirably:
- If node_modules is in place and you're reinstalling after switching branches:
```
yarn run install_all
```
- If node_modules is missing (fresh clone or deleted):
```
EMBARK_NO_PREPARE=t yarn install && yarn run install_all
```
It's not recommended to set `EMBARK_NO_PREPARE` in your environment (e.g. in
`.bashrc`) since that would interfere with embark's `release` script if/when
you run it.
-----------------
**1.** Specify embark's build-related steps in the `prepare` script of
package.json.
When embark is installed directly from GitHub the `prepare` script results in a
"pre install" phase (handled automatically by npm/yarn) that fetches
devDependencies, builds embark (including embark-ui), packs a tarball with the
same steps (minus testing and tree-checking) as would happen during an embark
release, and finally does a production install from that tarball.
Important point: installs from GitHub must be performed with yarn; they're no
longer possible with npm since during the "pre install" phase npm will honor
embark's `.npmrc` and `"engines"` settings.
The following will work correctly after this commit is merged:
```
yarn [global] add git+https://github.com/embark-framework/embark.git
```
Use of "hosted git" shortcuts (e.g. `embark-framework/embark#bracnh`) won't
work correctly because yarn doesn't fully support them. See:
https://github.com/yarnpkg/yarn/issues/5235.
It's important to use `git+https` urls. Following a succesful install with
`git+https` it is possible to use a "hosted git" shortcut or `https` url, but
that's owing to a subtle and unreliable interaction between yarn's cache and
yarn's logic for installing from a url/shortcut.
**2.** Adjust the npm configs (`.npmrc`) for embark/-ui so that `yarn run [cmd]
[--opt]` can be used in place of `npm run [cmd] -- [--opt]`.
Either way is okay for running scripts, they're equivalent, but note the
requirement to use `--` before specifying command options with `npm run`.
**3.** Introduce yarn configs (`.yarnrc`) for embark/-ui and include the
`check-files` directive.
H/t to @alaibe for the recommendation.
**4.** Ignore embark's `dist/typings` and `scripts` directories when packing a
tarball.
**5.** Refactor embark/-ui's npm-scripts in relation to the `prepare` script,
and make other small improvements.
Notably, if the environment variable `EMBARK_NO_PREPARE` is truthy (from JS
perspective) then embark's `prepare` script will exit early. This prevents
`install_all` and `prepare` from getting stuck in a loop (`install:core` uses
cross-env to set `EMBARK_NO_PREPARE`) and provides a mechanism for users to
skip the `prepare` script when doing a fresh install:
```
EMBARK_NO_PREPARE=t yarn install
```
**6.** Give `.js` extensions to node scripts in embark's `scripts/`, remove the
shebang lines, and have npm-scripts explicitly invoke them with node.
This arrangement works for all platforms: Linux, macOS, and Windows.
**7.** Adjust travis and appveyor configs.
Since at present there aren't any tests or other CI steps that make use of
embark-ui's production build, set `EMBARK_NO_PREPARE` in the CI environments
and invoke `build:node` directly.
Check the working tree after `yarn install` for embark/-ui. This detects
situations where changes should have been committed to `yarn.lock` but were
not. Check the working tree again at the end to detect situations where ignore
files should have been adjusted but were not. Both checks could also detect
other surprising behavior that needs to be investigated. Any time the working
tree is not clean (there are untracked files or changes) CI will fail.
Drop CI runs for node 8.11.3 because that version ships with an older npm that
results in unstaged changes to the test apps' `package-lock.json` files,
causing the working tree check to fail at the end of the CI run. A simple
workaround isn't apparent, but the matter can be revisited.
**8.** Refactor embark's `release` script in light of the `prepare` script.
Notably, do the push step only after `npm publish` completes successfully. This
allows embark's `prepare` and `prepublishOnly` scripts to detect problems
before a commit and tag are pushed to GitHub, avoiding a need to rebase/revert
the remote release branch; the local branch will still need to have a commit
dropped and tag deleted before rerunning the `release` script.
Prompt the user if the `release` script is not being run in `--dry-run` mode.
Provide additional visual indicators of `--dry-run` mode.
Force the user to supply `--repo-branch [branch]` if the intention is to
release from a branch other than `master`.
yarn.lock files are generated for embark and embark-ui, and their package.json
files and other npm related files are updated to support and require using yarn
for development of embark itself and for embark's CI.
Buggy behavior related to npm lock files makes the goal of reproducible builds
and hassle-free automated releases nearly impossible to achieve at
present. With npm's lock files disabled we rely on pinned dependencies (exact
versions only in the package.json files of embark and embark-ui) for a
hopefully good result. This is an experiment while the project is in an alpha
release phase, and if problems are experienced we can return to using
npm-shrinkwrap.json / package-lock.json, or we can investigate a transition to
the yarn package manager, for ourselves and possibly for our users too.
Allow for embark sources to be authored in TypeScript and/or JavaScript, and to
make use of upcoming features of the JS language. Sources in the src/ directory
are transpiled into the dist/ directory, and npm-scripts are provided to
support and automate various aspect of the build process. Source map support is
enabled at runtime, i.e. when invoking the embark cli and running embark's test
suite.
Michael Bradley, Jr
Anthony Laibe
Iuri Matias