- Red makes it look like something is wrong with the string.
- On Ubuntu-based systems, it looks kinda broken.
- The error markers (`>` and `^`) as well as invalid tokens are already
marked with red. By not having strings red, the most important
information -- the error location -- is more visible.
This is a continuation of commit fa1de5ce (PR #4572).
- Highlight the error location markers in bold red.
- Dim the line number gutter with grey.
- Don't highlight brackets. Few editor color schemes do.
- Add JSX tag highlighting.
- Don't highlight punctuators with bold. That looks bad on Ubuntu based
systems. Instead, highlight them the same way as JSX tags, which
results in really nice JSX highlighting.
- Highlight capitalized variable names.
- Make invalid tokens stand out with a red background.
* babel-core: add options for different parser/generator
* test for experiemental plugins, other babylon options
* fix passing options into parser
* Fix when no code is provided
* fixup tests
* fix tests again
* use filename and fallback to cwd
This allows in some case when you use other modules that use this source-map-support lib to get only a single version at the root of node_modules. For example, this can prevent issues when requiring using webpack Banner plugin (compiled code is not always requiring dependencies as you would expect).
* Support computed class property names (#4499)
** Depends on babel/babylon#121 **
* `babel-types`: Add `computed` field to `ClassProperty`
* `babel-plugin-transform-class-properties`: handle computed property names correctly
* `babel-generator`: add tests for class properties (computed/literal, static/instance)
* doc: Update babel-types with ClassProperty.computed
* chore(package): update babylon to v6.11.0
* babel-types: move ClassProperty.computed to be last builder arg
The filename options used by babylon is called `sourceFilename` and not `filename`. Therefore the option should be adjusted to be called `sourceFilename`.
* Flip default parameter template
YMMV, I saved ~10b on a 2kb library. Not noticeable at the small scale, by why not do it anyway?
I've (unscientifically) found that flipping the default parameter conditional yields better gzip results. I think this is due to the slightly longer string it can now repeatedly match:
```js
// old
var param = arguments.length <= 0 || void 0 === arguments[0] ? null : arguments[0]
--------------------------------------------------------------^
// new
var param = arguments.length > 1 && void 0 !== arguments[1] ? arguments[1] : null
------------------------------------------------------------------------^
```
Though it's entirely likely gzip will also choose up to the index of the arguments if you many default parameters at different indexes.
* Update tests
* Removed unnecessary 'return' statements.
Returning a 'Promise' value in 'promise.then()' makes promise chains.
Used memory and promises are not garbage collected
until finishing 'helpers.asyncToGenerator'.
* Update test
* Fix destructuring evaluation with call expressions
Do not optimize destructions with callExpressions, as the call
might change the value of a variable that we are assigning to.
Fixes#4054
* Also deopt on member expressions
members expressions might be getters who have side effects
* formatting
* fix `typeof Symbol.prototype`
Babel uses a helper function to return the correct value for `typeof
obj` when obj is a Symbol and support for Symbol has been polyfilled.
This function assumes that `obj.constructor === Symbol` implies `typeof
obj === 'symbol'`.
This isn't true when obj is `Symbol.prototype`. In that case (REPL from
node 6, the same holds in Firefox):
```
> Symbol.prototype.constructor === Symbol
true
> typeof Symbol.prototype
'object'
>
```
AFAICS, that's the only case where the assumption doesn't hold.
The test added by this patch fails only on node 0.10, as 0.12 already
has a native implementation of Symbol and the polyfill code doesn't run.
This caused a problem in core-js when it's compiled with babel (the
issue was isolated by @skozin here:
https://github.com/zloirock/core-js/issues/189#issuecomment-209864582).
