Add @openzeppelin/contracts as alternative package name (#1840)

* Rename package and repository name from docs and scripts

* undo root package rename

* add @openzeppelin/contracts as subpackage with release automation

* synchronize @openzeppelin/contracts version

* remove private field from package.json

* make file patterns absolute

* change wording of a comment

* use a saner version script

.github/ISSUE_TEMPLATE/feature_request.md

@@ -1,6 +1,6 @@
 ---
 name: Feature request
-about: Suggest an idea for OpenZeppelin
+about: Suggest an idea for OpenZeppelin Contracts
 
 ---
 
@@ -11,4 +11,4 @@ about: Suggest an idea for OpenZeppelin
 <!-- Please describe your feature request in detail. -->
 
 <!-- Make sure that you have reviewed the OpenZeppelin Contributor Guidelines. -->
-<!-- https://github.com/OpenZeppelin/openzeppelin-solidity/blob/master/CONTRIBUTING.md -->
+<!-- https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/CONTRIBUTING.md -->

.github/PULL_REQUEST_TEMPLATE.md

@@ -13,7 +13,7 @@ Fixes #
 
 <!-- 3. Before submitting, please make sure that you have:
   - reviewed the OpenZeppelin Contributor Guidelines
-    (https://github.com/OpenZeppelin/openzeppelin-solidity/blob/master/CONTRIBUTING.md),
+    (https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/CONTRIBUTING.md),
   - added tests where applicable to test new functionality,
   - made sure that your contracts are well-documented,
   - run the Solidity linter (`npm run lint:sol`) and fixed any issues,

.gitignore

@@ -44,3 +44,7 @@ build/
 # docs artifacts
 docs/modules/api
 openzeppelin-docs
+
+# only used to package @openzeppelin/contracts
+contracts/build/
+contracts/README.md

CONTRIBUTING.md

@@ -1,7 +1,7 @@
-Contributing to OpenZeppelin
+Contributing to OpenZeppelin Contracts
 =======
 
-We really appreciate and value contributions to OpenZeppelin. Please take 5' to review the items listed below to make sure that your contributions are merged as soon as possible.
+We really appreciate and value contributions to OpenZeppelin Contracts. Please take 5' to review the items listed below to make sure that your contributions are merged as soon as possible.
 
 ## Contribution guidelines
 
@@ -16,12 +16,12 @@ As a contributor, you are expected to fork this repository, work on your own for
 1) Make sure your fork is up to date with the main repository:
 
 ```
-cd openzeppelin-solidity
-git remote add upstream https://github.com/OpenZeppelin/openzeppelin-solidity.git
+cd openzeppelin-contracts
+git remote add upstream https://github.com/OpenZeppelin/openzeppelin-contracts.git
 git fetch upstream
 git pull --rebase upstream master
 ```
-NOTE: The directory `openzeppelin-solidity` represents your fork's local copy.
+NOTE: The directory `openzeppelin-contracts` represents your fork's local copy.
 
 2) Branch out from `master` into `fix/some-bug-#123`:
 (Postfixing #123 will associate your PR with the issue #123 and make everyone's life easier =D)
@@ -37,7 +37,7 @@ git commit "Fix some bug #123"
 git push origin fix/some-bug-#123
 ```
 
-4) Go to [github.com/OpenZeppelin/openzeppelin-solidity](https://github.com/OpenZeppelin/openzeppelin-solidity) in your web browser and issue a new pull request.
+4) Go to [github.com/OpenZeppelin/openzeppelin-contracts](https://github.com/OpenZeppelin/openzeppelin-contracts) in your web browser and issue a new pull request.
 
 *IMPORTANT* Read the PR template very carefully and make sure to follow all the instructions. These instructions
 refer to some very important conditions that your PR must meet in order to be accepted, such as making sure that all tests pass, JS linting tests pass, solidity linting tests pass, etc.
@@ -48,9 +48,9 @@ refer to some very important conditions that your PR must meet in order to be ac
 
 ## All set!
 
-If you have any questions feel free to post them to github.com/OpenZeppelin/openzeppelin-solidity/issues.
+If you have any questions feel free to post them to github.com/OpenZeppelin/openzeppelin-contracts/issues.
 
-Finally, if you're looking to collaborate and want to find easy tasks to start, look at the issues we marked as ["Good first issue"](https://github.com/OpenZeppelin/openzeppelin-solidity/labels/good%20first%20issue).
+Finally, if you're looking to collaborate and want to find easy tasks to start, look at the issues we marked as ["Good first issue"](https://github.com/OpenZeppelin/openzeppelin-contracts/labels/good%20first%20issue).
 
 Thanks for your time and code!
 

README.md

@@ -1,6 +1,6 @@
 # <img src="logo.png" alt="OpenZeppelin" height="40px">
 
-[![NPM Package](https://img.shields.io/npm/v/openzeppelin-solidity.svg)](https://www.npmjs.org/package/openzeppelin-solidity)
+[![NPM Package](https://img.shields.io/npm/v/@openzeppelin/contracts.svg)](https://www.npmjs.org/package/@openzeppelin/contracts)
 [![Build Status](https://travis-ci.com/OpenZeppelin/openzeppelin-contracts.svg?branch=master)](https://travis-ci.com/OpenZeppelin/openzeppelin-contracts)
 [![Coverage Status](https://coveralls.io/repos/github/OpenZeppelin/openzeppelin-contracts/badge.svg?branch=master)](https://coveralls.io/github/OpenZeppelin/openzeppelin-contracts?branch=master)
 
@@ -9,7 +9,7 @@
 ## Install
 
 ```
-npm install openzeppelin-solidity
+npm install @openzeppelin/contracts
 ```
 
 OpenZeppelin Contracts features a stable API, which means your contracts won't break unexpectedly when upgrading to a newer minor version. You can read ṫhe details in our [API Stability] document.
@@ -21,8 +21,8 @@ To write your custom contracts, import ours and extend them through inheritance.
 ```solidity
 pragma solidity ^0.5.0;
 
-import 'openzeppelin-solidity/contracts/token/ERC721/ERC721Full.sol';
-import 'openzeppelin-solidity/contracts/token/ERC721/ERC721Mintable.sol';
+import "@openzeppelin/contracts/token/ERC721/ERC721Full.sol";
+import "@openzeppelin/contracts/token/ERC721/ERC721Mintable.sol";
 
 contract MyNFT is ERC721Full, ERC721Mintable {
   constructor() ERC721Full("MyNFT", "MNFT") public {

RELEASING.md

@@ -2,7 +2,7 @@
 
 This document describes our release process, and contains the steps to be followed by an OpenZeppelin maintainer at the several stages of a release.
 
-We release a new version of OpenZeppelin monthly. Release cycles are tracked in the [issue milestones](https://github.com/OpenZeppelin/openzeppelin-solidity/milestones).
+We release a new version of OpenZeppelin monthly. Release cycles are tracked in the [issue milestones](https://github.com/OpenZeppelin/openzeppelin-contracts/milestones).
 
 Each release has at least one release candidate published first, intended for community review and any critical fixes that may come out of it. At the moment we leave 1 week between the first release candidate and the final release.
 
@@ -32,7 +32,7 @@ git push upstream release-vX.Y.Z
 git push upstream vX.Y.Z-rc.R
 ```
 
-Draft the release notes in our [GitHub releases](https://github.com/OpenZeppelin/openzeppelin-solidity/releases). Make sure to mark it as a pre-release! Try to be consistent with our previous release notes in the title and format of the text. Release candidates don't need a detailed changelog, but make sure to include a link to GitHub's compare page.
+Draft the release notes in our [GitHub releases](https://github.com/OpenZeppelin/openzeppelin-contracts/releases). Make sure to mark it as a pre-release! Try to be consistent with our previous release notes in the title and format of the text. Release candidates don't need a detailed changelog, but make sure to include a link to GitHub's compare page.
 
 Once the CI run for the new tag is green, publish on npm under the `next` tag. You should see the contracts compile automatically.
 
@@ -76,7 +76,7 @@ Publish the release notes on GitHub and ask our community manager to announce th
 Delete the `next` tag in the npm package as there is no longer a release candidate.
 
 ```
-npm dist-tag rm --otp $2FA_CODE openzeppelin-solidity next
+npm dist-tag rm --otp $2FA_CODE @openzeppelin/contracts next
 ```
 
 ## Merging the release branch

contracts/drafts/SignedSafeMath.sol

@@ -13,7 +13,7 @@ library SignedSafeMath {
     function mul(int256 a, int256 b) internal pure returns (int256) {
         // Gas optimization: this is cheaper than requiring 'a' not being zero, but the
         // benefit is lost if 'b' is also tested.
-        // See: https://github.com/OpenZeppelin/openzeppelin-solidity/pull/522
+        // See: https://github.com/OpenZeppelin/openzeppelin-contracts/pull/522
         if (a == 0) {
             return 0;
         }

contracts/math/SafeMath.sol

@@ -58,7 +58,7 @@ library SafeMath {
     function mul(uint256 a, uint256 b) internal pure returns (uint256) {
         // Gas optimization: this is cheaper than requiring 'a' not being zero, but the
         // benefit is lost if 'b' is also tested.
-        // See: https://github.com/OpenZeppelin/openzeppelin-solidity/pull/522
+        // See: https://github.com/OpenZeppelin/openzeppelin-contracts/pull/522
         if (a == 0) {
             return 0;
         }

contracts/package.json

@@ -0,0 +1,32 @@
+{
+  "name": "@openzeppelin/contracts",
+  "version": "2.3.0",
+  "description": "Secure Smart Contract library for Solidity",
+  "files": [
+    "**/*.sol",
+    "/build/*.json",
+    "!/mocks",
+    "!/examples"
+  ],
+  "scripts": {
+    "prepare": "bash ../scripts/prepare-contracts-package.sh"
+  },
+  "repository": {
+    "type": "git",
+    "url": "https://github.com/OpenZeppelin/openzeppelin-contracts.git"
+  },
+  "keywords": [
+    "solidity",
+    "ethereum",
+    "smart",
+    "contracts",
+    "security",
+    "zeppelin"
+  ],
+  "author": "OpenZeppelin Community <maintainers@openzeppelin.org>",
+  "license": "MIT",
+  "bugs": {
+    "url": "https://github.com/OpenZeppelin/openzeppelin-contracts/issues"
+  },
+  "homepage": "https://github.com/OpenZeppelin/openzeppelin-contracts"
+}

docs/modules/ROOT/pages/access-control.adoc

@@ -13,7 +13,7 @@ OpenZeppelin provides xref:api:ownership.adoc#Ownable[`Ownable`] for implementin
 ----
 pragma solidity ^0.5.0;
 
-import "openzeppelin-solidity/contracts/ownership/Ownable.sol";
+import "@openzeppelin/contracts/ownership/Ownable.sol";
 
 contract MyContract is Ownable {
     function normalThing() public {
@@ -58,9 +58,9 @@ Here's a simple example of using `Roles` in an xref:tokens.adoc#ERC20[`ERC20` to
 ----
 pragma solidity ^0.5.0;
 
-import "openzeppelin-solidity/contracts/access/Roles.sol";
-import "openzeppelin-solidity/contracts/token/ERC20/ERC20.sol";
-import "openzeppelin-solidity/contracts/token/ERC20/ERC20Detailed.sol";
+import "@openzeppelin/contracts/access/Roles.sol";
+import "@openzeppelin/contracts/token/ERC20/ERC20.sol";
+import "@openzeppelin/contracts/token/ERC20/ERC20Detailed.sol";
 
 contract MyToken is ERC20, ERC20Detailed {
     using Roles for Roles.Role;

docs/modules/ROOT/pages/api-stability.adoc

@@ -1,6 +1,6 @@
 = API Stability
 
-On the https://github.com/OpenZeppelin/openzeppelin-solidity/releases/tag/v2.0.0[OpenZeppelin 2.0 release], we committed ourselves to keeping a stable API. We aim to more precisely define what we understand by _stable_ and _API_ here, so users of the library can understand these guarantees and be confident their project won't break unexpectedly.
+On the https://github.com/OpenZeppelin/openzeppelin-contracts/releases/tag/v2.0.0[OpenZeppelin 2.0 release], we committed ourselves to keeping a stable API. We aim to more precisely define what we understand by _stable_ and _API_ here, so users of the library can understand these guarantees and be confident their project won't break unexpectedly.
 
 In a nutshell, the API being stable means _if your project is working today, it will continue to do so_. New contracts and features will be added in minor releases, but only in a backwards compatible way.
 
@@ -14,7 +14,7 @@ We follow https://semver.org/[SemVer], which means API breakage may occur betwee
 
 While the internal implementation of functions may change, their semantics and signature will remain the same. The domain of their arguments will not be less restrictive (e.g. if transferring a value of 0 is disallowed, it will remain disallowed), nor will general state restrictions be lifted (e.g. `whenPaused` modifiers).
 
-If new functions are added to a contract, it will be in a backwards-compatible way: their usage won't be mandatory, and they won't extend functionality in ways that may foreseeable break an application (e.g. https://github.com/OpenZeppelin/openzeppelin-solidity/issues/1512[an `internal` method may be added to make it easier to retrieve information that was already available]).
+If new functions are added to a contract, it will be in a backwards-compatible way: their usage won't be mandatory, and they won't extend functionality in ways that may foreseeable break an application (e.g. https://github.com/OpenZeppelin/openzeppelin-contracts/issues/1512[an `internal` method may be added to make it easier to retrieve information that was already available]).
 
 [[internal]]
 === `internal`
@@ -33,7 +33,7 @@ Some of our Solidity libraries use `struct`s to handle internal data that should
 [[events]]
 == Events
 
-No events will be removed, and their arguments won't be changed in any way. New events may be added in later versions, and existing events may be emitted under new, reasonable circumstances (e.g. https://github.com/OpenZeppelin/openzeppelin-solidity/issues/707[from 2.1 on, `ERC20` also emits `Approval` on `transferFrom` calls]).
+No events will be removed, and their arguments won't be changed in any way. New events may be added in later versions, and existing events may be emitted under new, reasonable circumstances (e.g. https://github.com/OpenZeppelin/openzeppelin-contracts/issues/707[from 2.1 on, `ERC20` also emits `Approval` on `transferFrom` calls]).
 
 [[gas-costs]]
 == Gas costs
@@ -43,7 +43,7 @@ While attempts will generally be made to lower the gas costs of working with Ope
 [[bugfixes]]
 == Bugfixes
 
-The API stability guarantees may need to be broken in order to fix a bug, and we will do so. This decision won't be made lightly however, and all options will be explored to make the change as non-disruptive as possible. When sufficient, contracts or functions which may result in unsafe behaviour will be deprecated instead of removed (e.g. https://github.com/OpenZeppelin/openzeppelin-solidity/pull/1543[#1543] and https://github.com/OpenZeppelin/openzeppelin-solidity/pull/1550[#1550]).
+The API stability guarantees may need to be broken in order to fix a bug, and we will do so. This decision won't be made lightly however, and all options will be explored to make the change as non-disruptive as possible. When sufficient, contracts or functions which may result in unsafe behaviour will be deprecated instead of removed (e.g. https://github.com/OpenZeppelin/openzeppelin-contracts/pull/1543[#1543] and https://github.com/OpenZeppelin/openzeppelin-contracts/pull/1550[#1550]).
 
 [[solidity-compiler-version]]
 == Solidity compiler version
@@ -52,4 +52,4 @@ Starting on version 0.5.0, the Solidity team switched to a faster release cycle,
 
 Because of this, *the minimum required Solidity compiler version is not part of the stability guarantees*, and users may be required to upgrade their compiler when using newer versions of OpenZeppelin. Bugfixes will still be backported to older library releases so that all versions currently in use receive these updates.
 
-You can read more about the rationale behind this, the other options we considered and why we went down this path https://github.com/OpenZeppelin/openzeppelin-solidity/issues/1498#issuecomment-449191611[here].
+You can read more about the rationale behind this, the other options we considered and why we went down this path https://github.com/OpenZeppelin/openzeppelin-contracts/issues/1498#issuecomment-449191611[here].

docs/modules/ROOT/pages/erc20-supply.adoc

@@ -4,7 +4,7 @@ In this guide you will learn how to create an ERC20 token with a custom supply m
 
 '''''
 
-The standard interface implemented by tokens built on Ethereum is called ERC20, and OpenZeppelin includes a widely used implementation of it: the aptly named https://github.com/OpenZeppelin/openzeppelin-solidity/blob/v2.1.2/contracts/token/ERC20/ERC20.sol[`ERC20`] contract. This contract, like the standard itself, is quite simple and bare-bones. In fact, if you try deploy an instance of `ERC20` as-is it will be quite literally useless... it will have no supply! What use is a token with no supply?
+The standard interface implemented by tokens built on Ethereum is called ERC20, and OpenZeppelin includes a widely used implementation of it: the aptly named https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v2.1.2/contracts/token/ERC20/ERC20.sol[`ERC20`] contract. This contract, like the standard itself, is quite simple and bare-bones. In fact, if you try deploy an instance of `ERC20` as-is it will be quite literally useless... it will have no supply! What use is a token with no supply?
 
 The way that supply is created is not defined in the ERC20 document. Every token is free to experiment with their own mechanisms, ranging from the most decentralized to the most centralized, from the most naive to the most researched, and more.
 
@@ -57,7 +57,7 @@ As we can see, `_mint` makes it super easy to do this correctly.
 [[modularizing-the-mechanism]]
 == Modularizing the mechanism
 
-There is one supply mechanism already included in OpenZeppelin: https://github.com/OpenZeppelin/openzeppelin-solidity/blob/v2.1.2/contracts/token/ERC20/ERC20Mintable.sol[`ERC20Mintable`]. This is a generic mechanism in which a set of accounts is assigned the `minter` role, granting them the permission to call a `mint` function, an external version of `_mint`.
+There is one supply mechanism already included in OpenZeppelin: https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v2.1.2/contracts/token/ERC20/ERC20Mintable.sol[`ERC20Mintable`]. This is a generic mechanism in which a set of accounts is assigned the `minter` role, granting them the permission to call a `mint` function, an external version of `_mint`.
 
 This can be used for centralized minting, where an externally owned account (i.e. someone with a pair of cryptographic keys) decides how much supply to create and to whom. There are very legitimate use cases for this mechanism, such as https://medium.com/reserve-currency/why-another-stablecoin-866f774afede#3aea[traditional asset-backed stablecoins].
 

docs/modules/ROOT/pages/index.adoc

@@ -5,7 +5,7 @@
 [[install]]
 == Install
 
-OpenZeppelin should be installed directly into your existing node.js project with `npm install openzeppelin-solidity`. We will use https://truffleframework.com/truffle[Truffle], an Ethereum development environment, to get started.
+OpenZeppelin should be installed directly into your existing node.js project with `npm install @openzeppelin/contracts`. We will use https://truffleframework.com/truffle[Truffle], an Ethereum development environment, to get started.
 
 Please install Truffle and initialize your project:
 
@@ -22,7 +22,7 @@ To install the OpenZeppelin library, run the following in your Solidity project
 
 [source,sh]
 ----
-$ npm install openzeppelin-solidity
+$ npm install @openzeppelin/contracts
 ----
 
 NOTE: OpenZeppelin features a stable API, which means your contracts won't break unexpectedly when upgrading to a newer minor version. You can read ṫhe details in our xref:api-stability.adoc[API Stability] document.
@@ -36,7 +36,7 @@ Once installed, you can start using the contracts in the library by importing th
 ----
 pragma solidity ^0.5.0;
 
-import 'openzeppelin-solidity/contracts/ownership/Ownable.sol';
+import "@openzeppelin/contracts/ownership/Ownable.sol";
 
 contract MyContract is Ownable {
   ...

docs/modules/ROOT/pages/release-schedule.adoc

@@ -1,17 +1,17 @@
 = Release Schedule
 
-OpenZeppelin follows a xref:api-stability.adoc[semantic versioning scheme].
+OpenZeppelin Contracts follows a xref:api-stability.adoc[semantic versioning scheme].
 
 [[minor-releases]]
 == Minor releases
 
-OpenZeppelin has a *5 week release cycle*. This means that every five weeks a new release is published.
+OpenZeppelin Contracts has a *5 week release cycle*. This means that every five weeks a new release is published.
 
-At the beginning of the release cycle we decide which issues we want to prioritize, and assign them to https://github.com/OpenZeppelin/openzeppelin-solidity/milestones[a milestone on GitHub]. During the next five weeks, they are worked on and fixed.
+At the beginning of the release cycle we decide which issues we want to prioritize, and assign them to https://github.com/OpenZeppelin/openzeppelin-contracts/milestones[a milestone on GitHub]. During the next five weeks, they are worked on and fixed.
 
 Once the milestone is complete, we publish a feature-frozen release candidate. The purpose of the release candidate is to have a period where the community can review the new code before the actual release. If important problems are discovered, several more release candidates may be required. After a week of no more changes to the release candidate, the new version is published.
 
 [[major-releases]]
 == Major releases
 
-Every several months a new major release may come out. These are not scheduled, but will be based on the need to release breaking changes such as a redesign of a core feature of the library (e.g. https://github.com/OpenZeppelin/openzeppelin-solidity/issues/1146[roles] in 2.0). Since we value stability, we aim for these to happen infrequently (expect no less than six months between majors). However, we may be forced to release one when there are big changes to the Solidity language.
+Every several months a new major release may come out. These are not scheduled, but will be based on the need to release breaking changes such as a redesign of a core feature of the library (e.g. https://github.com/OpenZeppelin/openzeppelin-contracts/issues/1146[roles] in 2.0). Since we value stability, we aim for these to happen infrequently (expect no less than six months between majors). However, we may be forced to release one when there are big changes to the Solidity language.

docs/modules/ROOT/pages/tokens.adoc

@@ -41,8 +41,8 @@ Here's what our GLD token might look like.
 ----
 pragma solidity ^0.5.0;
 
-import "openzeppelin-solidity/contracts/token/ERC20/ERC20.sol";
-import "openzeppelin-solidity/contracts/token/ERC20/ERC20Detailed.sol";
+import "@openzeppelin/contracts/token/ERC20/ERC20.sol";
+import "@openzeppelin/contracts/token/ERC20/ERC20Detailed.sol";
 
 contract GLDToken is ERC20, ERC20Detailed {
     constructor(uint256 initialSupply) ERC20Detailed("Gold", "GLD", 18) public {
@@ -104,8 +104,8 @@ Here's what a contract for tokenized items might look like:
 ----
 pragma solidity ^0.5.0;
 
-import "openzeppelin-solidity/contracts/token/ERC721/ERC721Full.sol";
-import "openzeppelin-solidity/contracts/drafts/Counters.sol";
+import "@openzeppelin/contracts/token/ERC721/ERC721Full.sol";
+import "@openzeppelin/contracts/drafts/Counters.sol";
 
 contract GameItem is ERC721Full {
     using Counters for Counters.Counter;
@@ -193,7 +193,7 @@ We will replicate the `GLD` example of the <<constructing-an-erc20-token-contrac
 ----
 pragma solidity ^0.5.0;
 
-import "openzeppelin-solidity/contracts/token/ERC777/ERC777.sol";
+import "@openzeppelin/contracts/token/ERC777/ERC777.sol";
 
 contract GLDToken is ERC777 {
     constructor(

package-lock.json

@@ -1,5 +1,5 @@
 {
-  "name": "openzeppelin-solidity",
+  "name": "@openzeppelin/contracts",
   "version": "2.3.0",
   "lockfileVersion": 1,
   "requires": true,
@@ -2543,7 +2543,7 @@
       "dependencies": {
         "pify": {
           "version": "2.3.0",
-          "resolved": "https://registry.npmjs.org/pify/-/pify-2.3.0.tgz",
+          "resolved": "http://registry.npmjs.org/pify/-/pify-2.3.0.tgz",
           "integrity": "sha1-7RQaasBDqEnqWISY59yosVMw6Qw=",
           "dev": true
         }
@@ -3021,7 +3021,7 @@
           "dependencies": {
             "pify": {
               "version": "2.3.0",
-              "resolved": "https://registry.npmjs.org/pify/-/pify-2.3.0.tgz",
+              "resolved": "http://registry.npmjs.org/pify/-/pify-2.3.0.tgz",
               "integrity": "sha1-7RQaasBDqEnqWISY59yosVMw6Qw=",
               "dev": true
             }
@@ -3038,7 +3038,7 @@
           "dependencies": {
             "pify": {
               "version": "2.3.0",
-              "resolved": "https://registry.npmjs.org/pify/-/pify-2.3.0.tgz",
+              "resolved": "http://registry.npmjs.org/pify/-/pify-2.3.0.tgz",
               "integrity": "sha1-7RQaasBDqEnqWISY59yosVMw6Qw=",
               "dev": true
             }
@@ -3871,7 +3871,7 @@
     },
     "fs-extra": {
       "version": "0.30.0",
-      "resolved": "https://registry.npmjs.org/fs-extra/-/fs-extra-0.30.0.tgz",
+      "resolved": "http://registry.npmjs.org/fs-extra/-/fs-extra-0.30.0.tgz",
       "integrity": "sha1-8jP/zAjU2n1DLapEl3aYnbHfk/A=",
       "dev": true,
       "requires": {
@@ -5369,7 +5369,7 @@
       "dependencies": {
         "pify": {
           "version": "2.3.0",
-          "resolved": "https://registry.npmjs.org/pify/-/pify-2.3.0.tgz",
+          "resolved": "http://registry.npmjs.org/pify/-/pify-2.3.0.tgz",
           "integrity": "sha1-7RQaasBDqEnqWISY59yosVMw6Qw=",
           "dev": true
         }
@@ -6298,7 +6298,7 @@
     },
     "jsonfile": {
       "version": "2.4.0",
-      "resolved": "https://registry.npmjs.org/jsonfile/-/jsonfile-2.4.0.tgz",
+      "resolved": "http://registry.npmjs.org/jsonfile/-/jsonfile-2.4.0.tgz",
       "integrity": "sha1-NzaitCi4e72gzIO1P6PWM6NcKug=",
       "dev": true,
       "requires": {

package.json

@@ -3,11 +3,11 @@
   "version": "2.3.0",
   "description": "Secure Smart Contract library for Solidity",
   "files": [
-    "build",
-    "contracts",
-    "!contracts/mocks",
-    "!contracts/examples",
-    "test/behaviors"
+    "/contracts/**/*.sol",
+    "/build/contracts/*.json",
+    "!/contracts/mocks",
+    "!/contracts/examples",
+    "/test/behaviors"
   ],
   "scripts": {
     "compile": "scripts/compile.sh",
@@ -22,12 +22,12 @@
     "lint:sol": "solhint --max-warnings 0 \"contracts/**/*.sol\"",
     "prepare": "node scripts/prepare.js",
     "release": "scripts/release/release.sh",
-    "version": "scripts/release/update-changelog-release-date.js && scripts/release/update-ethpm-version.js",
+    "version": "scripts/release/version.sh",
     "test": "scripts/test.sh"
   },
   "repository": {
     "type": "git",
-    "url": "https://github.com/OpenZeppelin/zeppelin-solidity.git"
+    "url": "https://github.com/OpenZeppelin/openzeppelin-contracts.git"
   },
   "keywords": [
     "solidity",
@@ -40,9 +40,9 @@
   "author": "OpenZeppelin Community <maintainers@openzeppelin.org>",
   "license": "MIT",
   "bugs": {
-    "url": "https://github.com/OpenZeppelin/zeppelin-solidity/issues"
+    "url": "https://github.com/OpenZeppelin/openzeppelin-contracts/issues"
   },
-  "homepage": "https://github.com/OpenZeppelin/zeppelin-solidity",
+  "homepage": "https://github.com/OpenZeppelin/openzeppelin-contracts",
   "devDependencies": {
     "chai": "^4.2.0",
     "concurrently": "^4.1.0",

scripts/prepare-contracts-package.sh

@@ -0,0 +1,12 @@
+#!/usr/bin/env bash
+
+# cd to the root of the repo
+cd "$(git rev-parse --show-toplevel)"
+
+# avoids re-compilation during publishing of both packages
+if [[ ! -v ALREADY_COMPILED ]]; then
+  npm run prepare
+fi
+
+cp README.md contracts/
+cp -Tr build/contracts contracts/build

scripts/release/release.sh

@@ -30,20 +30,32 @@ push_release_branch_and_tag() {
   git push upstream "$(current_release_branch)" "$(current_version)"
 }
 
-push_and_publish() {
+publish() {
   dist_tag="$1"
 
-  log "Pushing release branch and tags to upstream"
-  push_release_branch_and_tag
-
-  log "Publishing package on npm"
+  log "Publishing openzeppelin-solidity on npm"
   npm publish --tag "$dist_tag" --otp "$(prompt_otp)"
 
+  log "Publishing @openzeppelin/contracts on npm"
+  env ALREADY_COMPILED= \ # avoid re-compiling
+    npm publish contracts --tag "$dist_tag" --otp "$(prompt_otp)"
+
   if [[ "$dist_tag" == "latest" ]]; then
-    npm dist-tag rm --otp "$(prompt_otp)" openzeppelin-solidity next
+    otp="$(prompt_otp)"
+    npm dist-tag rm --otp "$otp" openzeppelin-solidity next
+    npm dist-tag rm --otp "$otp" @openzeppelin/contracts next
   fi
 }
 
+push_and_publish() {
+  dist_tag="$1"
+
+  log "Pushing release branch and tags to upstream"
+  push_release_branch_and_tag
+
+  publish "$dist_tag"
+}
+
 prompt_otp() {
   log -n "Enter npm 2FA token: "
   read -r otp

scripts/release/synchronize-versions.js

@@ -0,0 +1,18 @@
+#!/usr/bin/env node
+
+// Synchronizes the versions in ethpm.json and contracts/package.json with the
+// one in package.json.
+// This is run automatically when npm version is run.
+
+const fs = require('fs');
+const cp = require('child_process');
+
+setVersion('contracts/package.json');
+setVersion('ethpm.json');
+
+function setVersion(file) {
+  const json = JSON.parse(fs.readFileSync(file));
+  json.version = process.env.npm_package_version;
+  fs.writeFileSync(file, JSON.stringify(json, null, 2) + '\n');
+  cp.execFileSync('git', ['add', file]);
+}

scripts/release/update-ethpm-version.js

@@ -1,16 +0,0 @@
-#!/usr/bin/env node
-
-// Synchronizes ethpm.json version number with package.json.
-// This is run automatically when npm version is run.
-
-const fs = require('fs');
-const cp = require('child_process');
-
-const pkg = require('../../package.json');
-const ethpm = require('../../ethpm.json');
-
-ethpm.version = pkg.version;
-
-fs.writeFileSync('ethpm.json', JSON.stringify(ethpm, null, 2) + '\n');
-
-cp.execSync('git add ethpm.json');

scripts/release/version.sh

@@ -0,0 +1,6 @@
+#!/usr/bin/env bash
+
+set -o errexit
+
+scripts/release/update-changelog-release-date.js
+scripts/release/synchronize-versions.js