Compile invariant directly to throw expressions (#15071)
* Transform invariant to custom error type
This transforms calls to the invariant module:
```js
invariant(condition, 'A %s message that contains %s', adj, noun);
```
Into throw statements:
```js
if (!condition) {
if (__DEV__) {
throw ReactError(`A ${adj} message that contains ${noun}`);
} else {
throw ReactErrorProd(ERR_CODE, adj, noun);
}
}
```
The only thing ReactError does is return an error whose name is set
to "Invariant Violation" to match the existing behavior.
ReactErrorProd is a special version used in production that throws
a minified error code, with a link to see to expanded form. This
replaces the reactProdInvariant module.
As a next step, I would like to replace our use of the invariant module
for user facing errors by transforming normal Error constructors to
ReactError and ReactErrorProd. (We can continue using invariant for
internal React errors that are meant to be unreachable, which was the
original purpose of invariant.)
* Use numbers instead of strings for error codes
* Use arguments instead of an array
I wasn't sure about this part so I asked Sebastian, and his rationale
was that using arguments will make ReactErrorProd slightly slower, but
using an array will likely make all the functions that throw slightly
slower to compile, so it's hard to say which way is better. But since
ReactErrorProd is in an error path, and fewer bytes is generally better,
no array is good.
* Casing nit
2019-03-18 13:58:03 -07:00
|
|
|
/**
|
|
|
|
|
* Copyright (c) Facebook, Inc. and its affiliates.
|
|
|
|
|
*
|
|
|
|
|
* This source code is licensed under the MIT license found in the
|
|
|
|
|
* LICENSE file in the root directory of this source tree.
|
|
|
|
|
*/
|
|
|
|
|
'use strict';
|
|
|
|
|
|
|
|
|
|
const fs = require('fs');
|
|
|
|
|
const evalToString = require('../shared/evalToString');
|
|
|
|
|
const invertObject = require('./invertObject');
|
2019-08-08 17:46:35 -07:00
|
|
|
const helperModuleImports = require('@babel/helper-module-imports');
|
Compile invariant directly to throw expressions (#15071)
* Transform invariant to custom error type
This transforms calls to the invariant module:
```js
invariant(condition, 'A %s message that contains %s', adj, noun);
```
Into throw statements:
```js
if (!condition) {
if (__DEV__) {
throw ReactError(`A ${adj} message that contains ${noun}`);
} else {
throw ReactErrorProd(ERR_CODE, adj, noun);
}
}
```
The only thing ReactError does is return an error whose name is set
to "Invariant Violation" to match the existing behavior.
ReactErrorProd is a special version used in production that throws
a minified error code, with a link to see to expanded form. This
replaces the reactProdInvariant module.
As a next step, I would like to replace our use of the invariant module
for user facing errors by transforming normal Error constructors to
ReactError and ReactErrorProd. (We can continue using invariant for
internal React errors that are meant to be unreachable, which was the
original purpose of invariant.)
* Use numbers instead of strings for error codes
* Use arguments instead of an array
I wasn't sure about this part so I asked Sebastian, and his rationale
was that using arguments will make ReactErrorProd slightly slower, but
using an array will likely make all the functions that throw slightly
slower to compile, so it's hard to say which way is better. But since
ReactErrorProd is in an error path, and fewer bytes is generally better,
no array is good.
* Casing nit
2019-03-18 13:58:03 -07:00
|
|
|
|
|
|
|
|
module.exports = function(babel) {
|
|
|
|
|
const t = babel.types;
|
|
|
|
|
|
|
|
|
|
const DEV_EXPRESSION = t.identifier('__DEV__');
|
|
|
|
|
|
|
|
|
|
return {
|
|
|
|
|
visitor: {
|
|
|
|
|
CallExpression(path, file) {
|
|
|
|
|
const node = path.node;
|
2019-04-09 16:40:19 -07:00
|
|
|
const noMinify = file.opts.noMinify;
|
Compile invariant directly to throw expressions (#15071)
* Transform invariant to custom error type
This transforms calls to the invariant module:
```js
invariant(condition, 'A %s message that contains %s', adj, noun);
```
Into throw statements:
```js
if (!condition) {
if (__DEV__) {
throw ReactError(`A ${adj} message that contains ${noun}`);
} else {
throw ReactErrorProd(ERR_CODE, adj, noun);
}
}
```
The only thing ReactError does is return an error whose name is set
to "Invariant Violation" to match the existing behavior.
ReactErrorProd is a special version used in production that throws
a minified error code, with a link to see to expanded form. This
replaces the reactProdInvariant module.
As a next step, I would like to replace our use of the invariant module
for user facing errors by transforming normal Error constructors to
ReactError and ReactErrorProd. (We can continue using invariant for
internal React errors that are meant to be unreachable, which was the
original purpose of invariant.)
* Use numbers instead of strings for error codes
* Use arguments instead of an array
I wasn't sure about this part so I asked Sebastian, and his rationale
was that using arguments will make ReactErrorProd slightly slower, but
using an array will likely make all the functions that throw slightly
slower to compile, so it's hard to say which way is better. But since
ReactErrorProd is in an error path, and fewer bytes is generally better,
no array is good.
* Casing nit
2019-03-18 13:58:03 -07:00
|
|
|
if (path.get('callee').isIdentifier({name: 'invariant'})) {
|
|
|
|
|
// Turns this code:
|
|
|
|
|
//
|
|
|
|
|
// invariant(condition, 'A %s message that contains %s', adj, noun);
|
|
|
|
|
//
|
|
|
|
|
// into this:
|
|
|
|
|
//
|
|
|
|
|
// if (!condition) {
|
2019-10-11 09:10:40 -07:00
|
|
|
// throw Error(
|
|
|
|
|
// __DEV__
|
|
|
|
|
// ? `A ${adj} message that contains ${noun}`
|
|
|
|
|
// : formatProdErrorMessage(ERR_CODE, adj, noun)
|
|
|
|
|
// );
|
Compile invariant directly to throw expressions (#15071)
* Transform invariant to custom error type
This transforms calls to the invariant module:
```js
invariant(condition, 'A %s message that contains %s', adj, noun);
```
Into throw statements:
```js
if (!condition) {
if (__DEV__) {
throw ReactError(`A ${adj} message that contains ${noun}`);
} else {
throw ReactErrorProd(ERR_CODE, adj, noun);
}
}
```
The only thing ReactError does is return an error whose name is set
to "Invariant Violation" to match the existing behavior.
ReactErrorProd is a special version used in production that throws
a minified error code, with a link to see to expanded form. This
replaces the reactProdInvariant module.
As a next step, I would like to replace our use of the invariant module
for user facing errors by transforming normal Error constructors to
ReactError and ReactErrorProd. (We can continue using invariant for
internal React errors that are meant to be unreachable, which was the
original purpose of invariant.)
* Use numbers instead of strings for error codes
* Use arguments instead of an array
I wasn't sure about this part so I asked Sebastian, and his rationale
was that using arguments will make ReactErrorProd slightly slower, but
using an array will likely make all the functions that throw slightly
slower to compile, so it's hard to say which way is better. But since
ReactErrorProd is in an error path, and fewer bytes is generally better,
no array is good.
* Casing nit
2019-03-18 13:58:03 -07:00
|
|
|
// }
|
|
|
|
|
//
|
|
|
|
|
// where ERR_CODE is an error code: a unique identifier (a number
|
|
|
|
|
// string) that references a verbose error message. The mapping is
|
|
|
|
|
// stored in `scripts/error-codes/codes.json`.
|
|
|
|
|
const condition = node.arguments[0];
|
|
|
|
|
const errorMsgLiteral = evalToString(node.arguments[1]);
|
|
|
|
|
const errorMsgExpressions = Array.from(node.arguments.slice(2));
|
|
|
|
|
const errorMsgQuasis = errorMsgLiteral
|
|
|
|
|
.split('%s')
|
|
|
|
|
.map(raw => t.templateElement({raw, cooked: String.raw({raw})}));
|
|
|
|
|
|
|
|
|
|
// Outputs:
|
2019-10-11 09:10:40 -07:00
|
|
|
// `A ${adj} message that contains ${noun}`;
|
|
|
|
|
const devMessage = t.templateLiteral(
|
|
|
|
|
errorMsgQuasis,
|
|
|
|
|
errorMsgExpressions
|
Compile invariant directly to throw expressions (#15071)
* Transform invariant to custom error type
This transforms calls to the invariant module:
```js
invariant(condition, 'A %s message that contains %s', adj, noun);
```
Into throw statements:
```js
if (!condition) {
if (__DEV__) {
throw ReactError(`A ${adj} message that contains ${noun}`);
} else {
throw ReactErrorProd(ERR_CODE, adj, noun);
}
}
```
The only thing ReactError does is return an error whose name is set
to "Invariant Violation" to match the existing behavior.
ReactErrorProd is a special version used in production that throws
a minified error code, with a link to see to expanded form. This
replaces the reactProdInvariant module.
As a next step, I would like to replace our use of the invariant module
for user facing errors by transforming normal Error constructors to
ReactError and ReactErrorProd. (We can continue using invariant for
internal React errors that are meant to be unreachable, which was the
original purpose of invariant.)
* Use numbers instead of strings for error codes
* Use arguments instead of an array
I wasn't sure about this part so I asked Sebastian, and his rationale
was that using arguments will make ReactErrorProd slightly slower, but
using an array will likely make all the functions that throw slightly
slower to compile, so it's hard to say which way is better. But since
ReactErrorProd is in an error path, and fewer bytes is generally better,
no array is good.
* Casing nit
2019-03-18 13:58:03 -07:00
|
|
|
);
|
|
|
|
|
|
2019-09-30 11:14:51 -07:00
|
|
|
const parentStatementPath = path.parentPath;
|
|
|
|
|
if (parentStatementPath.type !== 'ExpressionStatement') {
|
|
|
|
|
throw path.buildCodeFrameError(
|
|
|
|
|
'invariant() cannot be called from expression context. Move ' +
|
|
|
|
|
'the call to its own statement.'
|
|
|
|
|
);
|
|
|
|
|
}
|
|
|
|
|
|
2019-05-29 14:20:29 -07:00
|
|
|
if (noMinify) {
|
|
|
|
|
// Error minification is disabled for this build.
|
|
|
|
|
//
|
|
|
|
|
// Outputs:
|
|
|
|
|
// if (!condition) {
|
2019-10-11 09:10:40 -07:00
|
|
|
// throw Error(`A ${adj} message that contains ${noun}`);
|
2019-05-29 14:20:29 -07:00
|
|
|
// }
|
2019-09-30 11:14:51 -07:00
|
|
|
parentStatementPath.replaceWith(
|
2019-05-29 14:20:29 -07:00
|
|
|
t.ifStatement(
|
|
|
|
|
t.unaryExpression('!', condition),
|
2019-10-11 09:10:40 -07:00
|
|
|
t.blockStatement([
|
|
|
|
|
t.throwStatement(
|
|
|
|
|
t.callExpression(t.identifier('Error'), [devMessage])
|
|
|
|
|
),
|
|
|
|
|
])
|
2019-05-29 14:20:29 -07:00
|
|
|
)
|
|
|
|
|
);
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
Compile invariant directly to throw expressions (#15071)
* Transform invariant to custom error type
This transforms calls to the invariant module:
```js
invariant(condition, 'A %s message that contains %s', adj, noun);
```
Into throw statements:
```js
if (!condition) {
if (__DEV__) {
throw ReactError(`A ${adj} message that contains ${noun}`);
} else {
throw ReactErrorProd(ERR_CODE, adj, noun);
}
}
```
The only thing ReactError does is return an error whose name is set
to "Invariant Violation" to match the existing behavior.
ReactErrorProd is a special version used in production that throws
a minified error code, with a link to see to expanded form. This
replaces the reactProdInvariant module.
As a next step, I would like to replace our use of the invariant module
for user facing errors by transforming normal Error constructors to
ReactError and ReactErrorProd. (We can continue using invariant for
internal React errors that are meant to be unreachable, which was the
original purpose of invariant.)
* Use numbers instead of strings for error codes
* Use arguments instead of an array
I wasn't sure about this part so I asked Sebastian, and his rationale
was that using arguments will make ReactErrorProd slightly slower, but
using an array will likely make all the functions that throw slightly
slower to compile, so it's hard to say which way is better. But since
ReactErrorProd is in an error path, and fewer bytes is generally better,
no array is good.
* Casing nit
2019-03-18 13:58:03 -07:00
|
|
|
// Avoid caching because we write it as we go.
|
|
|
|
|
const existingErrorMap = JSON.parse(
|
|
|
|
|
fs.readFileSync(__dirname + '/codes.json', 'utf-8')
|
|
|
|
|
);
|
|
|
|
|
const errorMap = invertObject(existingErrorMap);
|
|
|
|
|
|
|
|
|
|
let prodErrorId = errorMap[errorMsgLiteral];
|
2019-05-29 14:20:29 -07:00
|
|
|
|
|
|
|
|
if (prodErrorId === undefined) {
|
|
|
|
|
// There is no error code for this message. Add an inline comment
|
|
|
|
|
// that flags this as an unminified error. This allows the build
|
|
|
|
|
// to proceed, while also allowing a post-build linter to detect it.
|
Compile invariant directly to throw expressions (#15071)
* Transform invariant to custom error type
This transforms calls to the invariant module:
```js
invariant(condition, 'A %s message that contains %s', adj, noun);
```
Into throw statements:
```js
if (!condition) {
if (__DEV__) {
throw ReactError(`A ${adj} message that contains ${noun}`);
} else {
throw ReactErrorProd(ERR_CODE, adj, noun);
}
}
```
The only thing ReactError does is return an error whose name is set
to "Invariant Violation" to match the existing behavior.
ReactErrorProd is a special version used in production that throws
a minified error code, with a link to see to expanded form. This
replaces the reactProdInvariant module.
As a next step, I would like to replace our use of the invariant module
for user facing errors by transforming normal Error constructors to
ReactError and ReactErrorProd. (We can continue using invariant for
internal React errors that are meant to be unreachable, which was the
original purpose of invariant.)
* Use numbers instead of strings for error codes
* Use arguments instead of an array
I wasn't sure about this part so I asked Sebastian, and his rationale
was that using arguments will make ReactErrorProd slightly slower, but
using an array will likely make all the functions that throw slightly
slower to compile, so it's hard to say which way is better. But since
ReactErrorProd is in an error path, and fewer bytes is generally better,
no array is good.
* Casing nit
2019-03-18 13:58:03 -07:00
|
|
|
//
|
|
|
|
|
// Outputs:
|
2019-05-29 14:20:29 -07:00
|
|
|
// /* FIXME (minify-errors-in-prod): Unminified error message in production build! */
|
Compile invariant directly to throw expressions (#15071)
* Transform invariant to custom error type
This transforms calls to the invariant module:
```js
invariant(condition, 'A %s message that contains %s', adj, noun);
```
Into throw statements:
```js
if (!condition) {
if (__DEV__) {
throw ReactError(`A ${adj} message that contains ${noun}`);
} else {
throw ReactErrorProd(ERR_CODE, adj, noun);
}
}
```
The only thing ReactError does is return an error whose name is set
to "Invariant Violation" to match the existing behavior.
ReactErrorProd is a special version used in production that throws
a minified error code, with a link to see to expanded form. This
replaces the reactProdInvariant module.
As a next step, I would like to replace our use of the invariant module
for user facing errors by transforming normal Error constructors to
ReactError and ReactErrorProd. (We can continue using invariant for
internal React errors that are meant to be unreachable, which was the
original purpose of invariant.)
* Use numbers instead of strings for error codes
* Use arguments instead of an array
I wasn't sure about this part so I asked Sebastian, and his rationale
was that using arguments will make ReactErrorProd slightly slower, but
using an array will likely make all the functions that throw slightly
slower to compile, so it's hard to say which way is better. But since
ReactErrorProd is in an error path, and fewer bytes is generally better,
no array is good.
* Casing nit
2019-03-18 13:58:03 -07:00
|
|
|
// if (!condition) {
|
2019-10-11 09:10:40 -07:00
|
|
|
// throw Error(`A ${adj} message that contains ${noun}`);
|
Compile invariant directly to throw expressions (#15071)
* Transform invariant to custom error type
This transforms calls to the invariant module:
```js
invariant(condition, 'A %s message that contains %s', adj, noun);
```
Into throw statements:
```js
if (!condition) {
if (__DEV__) {
throw ReactError(`A ${adj} message that contains ${noun}`);
} else {
throw ReactErrorProd(ERR_CODE, adj, noun);
}
}
```
The only thing ReactError does is return an error whose name is set
to "Invariant Violation" to match the existing behavior.
ReactErrorProd is a special version used in production that throws
a minified error code, with a link to see to expanded form. This
replaces the reactProdInvariant module.
As a next step, I would like to replace our use of the invariant module
for user facing errors by transforming normal Error constructors to
ReactError and ReactErrorProd. (We can continue using invariant for
internal React errors that are meant to be unreachable, which was the
original purpose of invariant.)
* Use numbers instead of strings for error codes
* Use arguments instead of an array
I wasn't sure about this part so I asked Sebastian, and his rationale
was that using arguments will make ReactErrorProd slightly slower, but
using an array will likely make all the functions that throw slightly
slower to compile, so it's hard to say which way is better. But since
ReactErrorProd is in an error path, and fewer bytes is generally better,
no array is good.
* Casing nit
2019-03-18 13:58:03 -07:00
|
|
|
// }
|
2019-10-11 09:10:40 -07:00
|
|
|
parentStatementPath.replaceWith(
|
Compile invariant directly to throw expressions (#15071)
* Transform invariant to custom error type
This transforms calls to the invariant module:
```js
invariant(condition, 'A %s message that contains %s', adj, noun);
```
Into throw statements:
```js
if (!condition) {
if (__DEV__) {
throw ReactError(`A ${adj} message that contains ${noun}`);
} else {
throw ReactErrorProd(ERR_CODE, adj, noun);
}
}
```
The only thing ReactError does is return an error whose name is set
to "Invariant Violation" to match the existing behavior.
ReactErrorProd is a special version used in production that throws
a minified error code, with a link to see to expanded form. This
replaces the reactProdInvariant module.
As a next step, I would like to replace our use of the invariant module
for user facing errors by transforming normal Error constructors to
ReactError and ReactErrorProd. (We can continue using invariant for
internal React errors that are meant to be unreachable, which was the
original purpose of invariant.)
* Use numbers instead of strings for error codes
* Use arguments instead of an array
I wasn't sure about this part so I asked Sebastian, and his rationale
was that using arguments will make ReactErrorProd slightly slower, but
using an array will likely make all the functions that throw slightly
slower to compile, so it's hard to say which way is better. But since
ReactErrorProd is in an error path, and fewer bytes is generally better,
no array is good.
* Casing nit
2019-03-18 13:58:03 -07:00
|
|
|
t.ifStatement(
|
|
|
|
|
t.unaryExpression('!', condition),
|
2019-10-11 09:10:40 -07:00
|
|
|
t.blockStatement([
|
|
|
|
|
t.throwStatement(
|
|
|
|
|
t.callExpression(t.identifier('Error'), [devMessage])
|
|
|
|
|
),
|
|
|
|
|
])
|
Compile invariant directly to throw expressions (#15071)
* Transform invariant to custom error type
This transforms calls to the invariant module:
```js
invariant(condition, 'A %s message that contains %s', adj, noun);
```
Into throw statements:
```js
if (!condition) {
if (__DEV__) {
throw ReactError(`A ${adj} message that contains ${noun}`);
} else {
throw ReactErrorProd(ERR_CODE, adj, noun);
}
}
```
The only thing ReactError does is return an error whose name is set
to "Invariant Violation" to match the existing behavior.
ReactErrorProd is a special version used in production that throws
a minified error code, with a link to see to expanded form. This
replaces the reactProdInvariant module.
As a next step, I would like to replace our use of the invariant module
for user facing errors by transforming normal Error constructors to
ReactError and ReactErrorProd. (We can continue using invariant for
internal React errors that are meant to be unreachable, which was the
original purpose of invariant.)
* Use numbers instead of strings for error codes
* Use arguments instead of an array
I wasn't sure about this part so I asked Sebastian, and his rationale
was that using arguments will make ReactErrorProd slightly slower, but
using an array will likely make all the functions that throw slightly
slower to compile, so it's hard to say which way is better. But since
ReactErrorProd is in an error path, and fewer bytes is generally better,
no array is good.
* Casing nit
2019-03-18 13:58:03 -07:00
|
|
|
)
|
|
|
|
|
);
|
2019-10-11 09:10:40 -07:00
|
|
|
parentStatementPath.addComment(
|
2019-05-29 14:20:29 -07:00
|
|
|
'leading',
|
|
|
|
|
'FIXME (minify-errors-in-prod): Unminified error message in production build!'
|
|
|
|
|
);
|
Compile invariant directly to throw expressions (#15071)
* Transform invariant to custom error type
This transforms calls to the invariant module:
```js
invariant(condition, 'A %s message that contains %s', adj, noun);
```
Into throw statements:
```js
if (!condition) {
if (__DEV__) {
throw ReactError(`A ${adj} message that contains ${noun}`);
} else {
throw ReactErrorProd(ERR_CODE, adj, noun);
}
}
```
The only thing ReactError does is return an error whose name is set
to "Invariant Violation" to match the existing behavior.
ReactErrorProd is a special version used in production that throws
a minified error code, with a link to see to expanded form. This
replaces the reactProdInvariant module.
As a next step, I would like to replace our use of the invariant module
for user facing errors by transforming normal Error constructors to
ReactError and ReactErrorProd. (We can continue using invariant for
internal React errors that are meant to be unreachable, which was the
original purpose of invariant.)
* Use numbers instead of strings for error codes
* Use arguments instead of an array
I wasn't sure about this part so I asked Sebastian, and his rationale
was that using arguments will make ReactErrorProd slightly slower, but
using an array will likely make all the functions that throw slightly
slower to compile, so it's hard to say which way is better. But since
ReactErrorProd is in an error path, and fewer bytes is generally better,
no array is good.
* Casing nit
2019-03-18 13:58:03 -07:00
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
prodErrorId = parseInt(prodErrorId, 10);
|
|
|
|
|
|
|
|
|
|
// Import ReactErrorProd
|
2019-10-11 09:10:40 -07:00
|
|
|
const formatProdErrorMessageIdentifier = helperModuleImports.addDefault(
|
2019-08-08 17:46:35 -07:00
|
|
|
path,
|
2019-10-11 09:10:40 -07:00
|
|
|
'shared/formatProdErrorMessage',
|
|
|
|
|
{nameHint: 'formatProdErrorMessage'}
|
Compile invariant directly to throw expressions (#15071)
* Transform invariant to custom error type
This transforms calls to the invariant module:
```js
invariant(condition, 'A %s message that contains %s', adj, noun);
```
Into throw statements:
```js
if (!condition) {
if (__DEV__) {
throw ReactError(`A ${adj} message that contains ${noun}`);
} else {
throw ReactErrorProd(ERR_CODE, adj, noun);
}
}
```
The only thing ReactError does is return an error whose name is set
to "Invariant Violation" to match the existing behavior.
ReactErrorProd is a special version used in production that throws
a minified error code, with a link to see to expanded form. This
replaces the reactProdInvariant module.
As a next step, I would like to replace our use of the invariant module
for user facing errors by transforming normal Error constructors to
ReactError and ReactErrorProd. (We can continue using invariant for
internal React errors that are meant to be unreachable, which was the
original purpose of invariant.)
* Use numbers instead of strings for error codes
* Use arguments instead of an array
I wasn't sure about this part so I asked Sebastian, and his rationale
was that using arguments will make ReactErrorProd slightly slower, but
using an array will likely make all the functions that throw slightly
slower to compile, so it's hard to say which way is better. But since
ReactErrorProd is in an error path, and fewer bytes is generally better,
no array is good.
* Casing nit
2019-03-18 13:58:03 -07:00
|
|
|
);
|
|
|
|
|
|
|
|
|
|
// Outputs:
|
2019-10-11 09:10:40 -07:00
|
|
|
// formatProdErrorMessage(ERR_CODE, adj, noun);
|
|
|
|
|
const prodMessage = t.callExpression(
|
|
|
|
|
formatProdErrorMessageIdentifier,
|
|
|
|
|
[t.numericLiteral(prodErrorId), ...errorMsgExpressions]
|
Compile invariant directly to throw expressions (#15071)
* Transform invariant to custom error type
This transforms calls to the invariant module:
```js
invariant(condition, 'A %s message that contains %s', adj, noun);
```
Into throw statements:
```js
if (!condition) {
if (__DEV__) {
throw ReactError(`A ${adj} message that contains ${noun}`);
} else {
throw ReactErrorProd(ERR_CODE, adj, noun);
}
}
```
The only thing ReactError does is return an error whose name is set
to "Invariant Violation" to match the existing behavior.
ReactErrorProd is a special version used in production that throws
a minified error code, with a link to see to expanded form. This
replaces the reactProdInvariant module.
As a next step, I would like to replace our use of the invariant module
for user facing errors by transforming normal Error constructors to
ReactError and ReactErrorProd. (We can continue using invariant for
internal React errors that are meant to be unreachable, which was the
original purpose of invariant.)
* Use numbers instead of strings for error codes
* Use arguments instead of an array
I wasn't sure about this part so I asked Sebastian, and his rationale
was that using arguments will make ReactErrorProd slightly slower, but
using an array will likely make all the functions that throw slightly
slower to compile, so it's hard to say which way is better. But since
ReactErrorProd is in an error path, and fewer bytes is generally better,
no array is good.
* Casing nit
2019-03-18 13:58:03 -07:00
|
|
|
);
|
|
|
|
|
|
|
|
|
|
// Outputs:
|
2019-10-11 09:10:40 -07:00
|
|
|
// if (!condition) {
|
|
|
|
|
// throw Error(
|
|
|
|
|
// __DEV__
|
|
|
|
|
// ? `A ${adj} message that contains ${noun}`
|
|
|
|
|
// : formatProdErrorMessage(ERR_CODE, adj, noun)
|
|
|
|
|
// );
|
|
|
|
|
// }
|
2019-09-30 11:14:51 -07:00
|
|
|
parentStatementPath.replaceWith(
|
Compile invariant directly to throw expressions (#15071)
* Transform invariant to custom error type
This transforms calls to the invariant module:
```js
invariant(condition, 'A %s message that contains %s', adj, noun);
```
Into throw statements:
```js
if (!condition) {
if (__DEV__) {
throw ReactError(`A ${adj} message that contains ${noun}`);
} else {
throw ReactErrorProd(ERR_CODE, adj, noun);
}
}
```
The only thing ReactError does is return an error whose name is set
to "Invariant Violation" to match the existing behavior.
ReactErrorProd is a special version used in production that throws
a minified error code, with a link to see to expanded form. This
replaces the reactProdInvariant module.
As a next step, I would like to replace our use of the invariant module
for user facing errors by transforming normal Error constructors to
ReactError and ReactErrorProd. (We can continue using invariant for
internal React errors that are meant to be unreachable, which was the
original purpose of invariant.)
* Use numbers instead of strings for error codes
* Use arguments instead of an array
I wasn't sure about this part so I asked Sebastian, and his rationale
was that using arguments will make ReactErrorProd slightly slower, but
using an array will likely make all the functions that throw slightly
slower to compile, so it's hard to say which way is better. But since
ReactErrorProd is in an error path, and fewer bytes is generally better,
no array is good.
* Casing nit
2019-03-18 13:58:03 -07:00
|
|
|
t.ifStatement(
|
|
|
|
|
t.unaryExpression('!', condition),
|
|
|
|
|
t.blockStatement([
|
2019-10-11 09:10:40 -07:00
|
|
|
t.blockStatement([
|
|
|
|
|
t.throwStatement(
|
|
|
|
|
t.callExpression(t.identifier('Error'), [
|
|
|
|
|
t.conditionalExpression(
|
|
|
|
|
DEV_EXPRESSION,
|
|
|
|
|
devMessage,
|
|
|
|
|
prodMessage
|
|
|
|
|
),
|
|
|
|
|
])
|
|
|
|
|
),
|
|
|
|
|
]),
|
Compile invariant directly to throw expressions (#15071)
* Transform invariant to custom error type
This transforms calls to the invariant module:
```js
invariant(condition, 'A %s message that contains %s', adj, noun);
```
Into throw statements:
```js
if (!condition) {
if (__DEV__) {
throw ReactError(`A ${adj} message that contains ${noun}`);
} else {
throw ReactErrorProd(ERR_CODE, adj, noun);
}
}
```
The only thing ReactError does is return an error whose name is set
to "Invariant Violation" to match the existing behavior.
ReactErrorProd is a special version used in production that throws
a minified error code, with a link to see to expanded form. This
replaces the reactProdInvariant module.
As a next step, I would like to replace our use of the invariant module
for user facing errors by transforming normal Error constructors to
ReactError and ReactErrorProd. (We can continue using invariant for
internal React errors that are meant to be unreachable, which was the
original purpose of invariant.)
* Use numbers instead of strings for error codes
* Use arguments instead of an array
I wasn't sure about this part so I asked Sebastian, and his rationale
was that using arguments will make ReactErrorProd slightly slower, but
using an array will likely make all the functions that throw slightly
slower to compile, so it's hard to say which way is better. But since
ReactErrorProd is in an error path, and fewer bytes is generally better,
no array is good.
* Casing nit
2019-03-18 13:58:03 -07:00
|
|
|
])
|
|
|
|
|
)
|
|
|
|
|
);
|
|
|
|
|
}
|
|
|
|
|
},
|
|
|
|
|
},
|
|
|
|
|
};
|
|
|
|
|
};
|