add startLine option

[alkhe]

Q	A
Bug fix?	no
Breaking change?	no
New feature?	yes
Deprecations?	no
Spec compliancy?	no
Tests added/pass?	yes
Fixed tickets
License	MIT

Adding a startLine option allows tool authors to more easily co-opt the babylon API with custom preprocessing.

Our team at RunKit would benefit from this feature.

[codecov-io]

Codecov Report

Merging #346 into master will not impact coverage.

@@           Coverage Diff           @@
##           master     #346   +/-   ##
=======================================
  Coverage   97.65%   97.65%           
=======================================
  Files          20       20           
  Lines        3326     3326           
  Branches      882      882           
=======================================
  Hits         3248     3248           
  Misses         30       30           
  Partials       48       48

Impacted Files	Coverage Δ
src/options.js	100% <ø> (ø)	✅
src/tokenizer/state.js	100% <100%> (ø)	✅

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 898c4a7...c0e579c. Read the comment docs.

[danez]

Can you describe a usecase where a tool wants to change the first line to be something different than 1?

[hzoo]

so specifically what's the usecase for runkit? (which is awesome btw)

[Me1000]

Hey there, I'm from the RunKit team. I've attached an image which should help explain things a bit better.

As you can see, cell 2, in this example, starts on line 5. We run each cell through Babel independently. The result is in this example that the generated SourceMap will maps line 1 of cell 2 to line line 1 (rather than line 5 of the notebook). In other words, each cell's first line will always map to line 1.

Our current workaround is to just insert new lines before we parse it. This PR will let us clean some of that up.

[danez]

I'm fine with that.

[loganfsmyth]

@Me1000 I'm curious, since you run each section through babel separately, do you not run into issues where Babel has renamed things? Take for example two snippets with

var fn = function(){
  console.log(fn);

}
fn = function(){};

fn();

I'd expect that to fail because Babel renames fn in the first snippet to _fn and the second snippet has no way to know about that.

[Me1000]

Great question. In short, we're applying our own custom transforms which (among other things) preserve those identifiers.

[loganfsmyth]

Okie doke, cool, just wanted to make sure since compiling separate snippets is not something we officially guarantee to work because of the renaming and such.