The Webpack config for the modern build was adjusted recently to add a loader,
which is used as a workaround for a bug introduced by a recent dependency
update. The legacy config needed the same update.
The Webpack config was also updated in superficial ways to follow
recommendations made for migrating from Webpack v1 to v2 (e.g. using
`module.rules` instead of `module.loaders`). These changes should have no
functional impact, and should make migrating to future versions of Webpack
easier.
fix#6269
<!-- Thanks for submitting a pull request! Please provide enough information so that others can review your pull request. The two fields below are mandatory. -->
**Summary**
Went down a rabbit hole with the formula, and noticed that the script wasn't updated.
<!-- Is the feature a substantial feature request? Please use https://github.com/yarnpkg/rfcs -->
<!-- Explain the **motivation** for making this change. What existing problem does the pull request solve? -->
**Test plan**
Not sure. @Daniel15 maybe has some thoughts?
<!-- Demonstrate the code is solid. Example: The exact commands you ran and their output, screenshots / videos if the pull request changes UI. -->
**Summary**
This diff simply adds a script to easily generate the changelog between the current tag and the previous one.
**Test plan**
Manually ran `yarn changelog`.
**Summary**
This PR removes the custom Docker image we have and adds all node versions to CircleCI tests. The
aim is to levearge increased granularity and parallelism that the new CircleCI workflows provide.
**Test plan**
All new steps on CircleCI should pass.
**Summary**
Yarn 1.1.0 release failed due to a bug in npm@5:
https://github.com/npm/npm/issues/16723. This patch uses `npx` to
force using `np@4` when publishing in `update-npm.sh`.
**Test plan**
CircleCI
* Fix: always use origin/master instead of master for homebrew
**Summary**
Fixes#3415. The old homebrew update script updated the repo
from remote but did not update the local `master` branch, thus
had the potential for conflicts and mismatches. This patch
forces it to use `origin/master` instead and uses the latest
up-to-date version from the source.
**Test plan**
N/A
* Stay on master
**Summary**
We've been using `node -p -e` where `-e` is redundant since
it is implied by `-p`: https://nodejs.org/api/cli.html#cli_p_print_script
This patch removes those extra `-e`s.
**Test plan**
All bundles should build on CI without errors.
**Summary**
Resolves#4021
This fixes the workspace command so that it runs in the correct directory and adds a test to validate it.
Previously the command was also relying on `process.argv` to get the executable path for `node` and `yarn`. However, that ends up being unreliable if yarn was run as part of another process (aka `jest`).
**Test plan**
Added integration tests.
**Summary**
Fixes#3758. Makes the top-level folder in the tar archives have a name like `yarn-vX.Y.Z` instead of `dist` using the `--transform` and `-s` options in `tar` (they are different in GNU and BSD `tar`).
**Test plan**
Run `yarn build-dist` and then `tar -ztvf artifacts/yarn-v1.0.0.tar.gz`. Make sure the output lists all the files under `yarn-v1.0.0` directory.
**Summary**
Fixes#4057.
**Test plan**
CI should pass, especially with `build-dist` job.
Manual:
- Run `yarn build-dist`
- Run `node artifacts/yarn-0.28.0.js --version`
- Run `./dist/bin/yarn --version`
Make sure all above commands work without errors.
**Summary**
Refs #3524. We are using `process.exit()` pretty liberally although it is [strongly advised not to use it](https://nodejs.org/api/process.html#process_process_exit_code) since it may cause the `stdout` to get corrupted/terminated before a full flush. This patch changes all possible `process.exit(code)` calls with `process.exitCode = code` statements.
We'd also ideally enable [no-process-exit](http://eslint.org/docs/rules/no-process-exit) rule in ESLint but it requires an upgrade to ESLint v4 which should be handled separately.
**Test plan**
Expect tests to pass and actually finish (not run indefinitely due to `yarn` not exiting at all). Also, the script referenced in #3524 to output something like the following:
```
DATA 18
DATA 8192
DATA 8192
DATA 5392
DATA 15
EXIT 0
```
* Remove unneeded package.json fields from dist
We don't need dependencies and devDependencies in the package.json within the Yarn distributable, as the dependencies are bundled with Yarn itself. We also don't need "scripts" or "jest" as they're purely for development
* Add script for publishing to npm
* Add Jenkins job for publishing to npm
* add prettier and prettying everything
* fix scripts and run yarn prettier
* fix scripts again and run yarn prettier
* use eslint-plugin-prettify instead of custom scripts
Instead of always grabbing the Yarn version number from yarnpkg.com, allow it to be passed in as command line argument.
Updates Jenkins bump-version job to pass it in.
References https://github.com/yarnpkg/website/issues/471
Instead of including all the raw JS files in the dist tarball, just use the single Yarn JS file that's built as part of the build, along with a few other files that are required. This significantly reduces the number of files in the tarball:
```
C:\src\yarn\dist (bundle-as-dist) (yarn@0.23.0-0)
λ find .
.
./bin
./bin/node-gyp-bin
./bin/node-gyp-bin/node-gyp
./bin/node-gyp-bin/node-gyp.cmd
./bin/yarn
./bin/yarn.cmd
./bin/yarn.js
./bin/yarnpkg
./bin/yarnpkg.cmd
./lib
./lib/v8-compile-cache.js
./lib/yarn-cli.js
./LICENSE
./package.json
```
There are three .js files in the archive:
- `lib/v8-compile-cache.js`: Speeds up instantiation time by using the V8 code cache (https://www.npmjs.com/package/v8-compile-cache). This needs to be separate as it has to load **before** the bulk of the application code is loaded, so it can **not** be bundled
- `lib/yarn-cli.js`: Contains all the bundled Yarn code
- `bin/yarn.js`: Entry point to the app, just like today. Loads `v8-compile-cache` then loads `yarn-cli`
This change means that **only** the JavaScript files that are actually used are included, resulting in a nice file size reduction for the installation packages:
Differences are due to differing compression algorithms: Debian packages use xz or LZMA, RedHat uses gzip, Windows installer uses Cabinet
They're also slightly faster to extract:
Testing was performed on my desktop computer (Intel Core i5 6500, Samsung 850 Evo 1TB SSD, Windows 10), with testing for Linux stuff (like installing the Debian package) tested in a Docker container.
Raw data: https://docs.google.com/spreadsheets/d/1d8jdf3DU_GUFdotlPl08PkYa8SkzStK2tgnQ54ivsm0/edit?usp=sharing
Performance is very slightly faster when using `v8-compile-cache` along with the bundled file, but it's not extremely significant (`yarn --version` went from 0.19s to 0.14s on my BuyVM server). The difference might be bigger on servers with slower disks (HDD) or with more overloaded servers.
I also deleted the `build-dist.ps1` file because we _should_ be able to assume that Bash is available on Windows, particularly if Git is installed (as it comes with Git Bash). I need to verify that this works on AppVeyor.
Previously, packages named with `-loader` suffix could be specified as loaders within Webpack without requiring the suffix to be named explicitly. Webpack 2.1.0-beta.26 no longer looks for `-loader` suffix automatically, and packages have to therefore be named explicitly or `-loader` can be added to `resolveLoader.moduleExtensions`.
See: https://github.com/webpack/webpack/releases/tag/v2.1.0-beta.26
- Old versions of Mac OS (10.10 and below) require the `-t` option for `mktemp`
- The check for GPG wasn't returning correctly, and tried to run GPG even when not available
Closes#2012Closes#1984
* Add automatic check for updates that nags the user when there's a new version available - fixes#1138
* remove self-update
* add support for updating yarn to tarball installer
* use new installationMethod package.json value to output update command
* address comments from @Daniel15
* remove self update tests
