Template literal validation #10492
Template literal validation #10492
Conversation
|
Build successful! You can test your changes in the REPL here: https://babeljs.io/repl/build/11725/ |
| ).toThrowErrorMatchingSnapshot(); | ||
|
|
||
| expect(() => | ||
| t.templateLiteral({}, ["baz"]), |
There was a problem hiding this comment.
The first needs to be an array, and the second an array of expressions (not a string).
There was a problem hiding this comment.
Those tests are put there intentionally to show that the previous validators still trigger and that the only time the new validation rule triggers is when that's the only thing wrong.
I can remove it though if it's considered irrelevant.
|
Thanks! |
Co-authored-by: Michael J. Currie <michaeljcurrie136@gmail.com>
nicolo-ribaudo
force-pushed
the
template-literal-validation
branch
from
9fc0623
to
9fd17ea
Compare
|
@Basaingeal I added |
|
Hey folks, after upgrading to recent @babel/types (namely 7.6.3) I started to get: The code I'm trying is dynamic import with const AsyncIcon = loadable(props => import(`./icons/${props.name}.js`));This was working fine with @babel/types 7.4.4. |
|
Could you open a new issue with your configuration? |
I've created a bug for @loadable/component, see above. I was just wondering what have actually changed with the fix, I think this is where they use |
lock
bot
added
the
outdated
I added a custom validation rule to the definition of
TemplateLiteralinpackages\babel-types\test\builders\es2015\templateElement.jsto check that the number of quasis is exactly one more than the number of expressions.I'm open to suggestions about the wording of the TypeError. I based it off of the number of quasis based off the wording of the issue, but I'm not sure if it needs to be in more layman's terms or more generalized or not.