* Fix default sourceFileName.
This deals with a problem mentioned in [babel/babelify#255][0]. I'm not
super sure about the implications, but it seems this may have been a
regression from Babel 6.
In babel@6, the default `sourceFileName` was the basename of the input
file:
```js
require('babel-core').transform('var a = 10', {
filename: __filename,
sourceMaps: true
}).map
// { version: 3,
// sources: [ 'index.js' ],
// names: [ 'a' ],
// mappings: 'AAAA,IAAIA,IAAI,EAAR',
// file: 'index.js',
// sourcesContent: [ 'var a = 10' ] } }
```
Currently however, the full file path is used:
```js
require('@babel/core').transformSync('var a = 10', {
filename: __filename,
sourceMaps: true
}).map
// { version: 3,
// sources: [ '/home/goto-bus-stop/Code/babel/repro-babelify-255/index.js' ],
// names: [ 'a' ],
// mappings: 'AAAA,IAAIA,IAAI,EAAR',
// file: '/home/goto-bus-stop/Code/babel/repro-babelify-255/index.js',
// sourcesContent: [ 'var a = 10' ] } }
```
This patch adds the `path.basename()` call that [Babel 6 used][1] to
@babel/core's default options, so it's the same as back then.
```js
require('../babel/packages/babel-core').transform('var a = 10', {
filename: __filename,
sourceMaps: true
}).map
// { version: 3,
// sources: [ 'index.js' ],
// names: [ 'a' ],
// mappings: 'AAAA,IAAIA,IAAI,EAAR',
// sourcesContent: [ 'var a = 10' ] }
```
This is the desired behaviour for browserify at least, as it expects
relative paths in the source maps and rebases them to a root directory
when generating the final source map.
[0]: https://github.com/babel/babelify/pull/255
[1]: 6689d2d23c/packages/babel-core/src/transformation/file/index.js (L163-L172)
* Use cwd-relative path for sourceFileName.
* Revert sourceMap `file` property change.
* fixup! Revert sourceMap `file` property change.
* Fix whitespace change from merge conflict
* Revert to using basename in source map outputs.
This undoes the property call folding from #6656.
It complicates the private property transforms, since they boil down to `map.set(this, vlaue)` and we definitely don't want the next call define a property on the map.
/cc @Andarist
Yes, the output is uglier. But, this is necessary for me to refactor
`replaceSupers` for #7733, which is necessary for both #7555 and
https://github.com/babel/babel/pull/7553#issuecomment-381434519.
I'm still in the middle of cleaning up all this code. Don't expect
`transformClass` to survive much longer as it's written currently.
We were using `Object.create` to setup the prototype chain at the start of the class definition, which lead to #7771.
I was a bit worried about a speed hit, but it seems everyone optimizes the two patterns the same way.
https://jsbench.github.io/#f9fca52407643d96458a35763b201215Fixes#7771.
* Implement MemberExpressionToFunctions helper
Fixes#7733.
This will also be used to simplify the Private Fields transform, which had [almost the same code](ccd941057a/packages/babel-plugin-proposal-class-properties/src/index.js (L114-L217)) hand written.
* Cleanup
* Little more comment cleanup
* Use unary plus
This can't be redefined, unlike the `Number` identifier.
* Review comments
* Remove unused deps
* drop support for Node.js v4; closes#7753
- remove version 4 from Travis build matrix
- update environment support doc
- update `CONTRIBUTING.md`
- update `engines` field of root `package.json`
Signed-off-by: Christopher Hiller <boneskull@boneskull.com>
* update engines for babylon
Signed-off-by: Christopher Hiller <boneskull@boneskull.com>
* Improve asyncIterator error
When an object is has neither asyncIterator or iterator defined, throw the "not an async iterable" error
* Correct logic
* reduce access
* Update helpers.js
