Giters

callumlocke / esbox

:package: ES.next in a box

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Local babel config isn't used

callumlocke opened this issue · comments

commented

Ideally the user's local Babel config should be used if found in scope of the file. Babel's require hook docs say this happens automatically, but it doesn't seem to happen with ESBox (based on one experiment).

commented

@callumlocke I am experiencing this when trying to use https://github.com/loganfsmyth/babel-plugin-transform-decorators-legacy with esbox. I've tried putting it in an rc file and also tried putting it in my local package.json under the babel key.

commented

Looks like if you use babel options you may need to point it to the .babelrc file that you want it to extend. See the "extends" option here: https://babeljs.io/docs/usage/options/#options

commented

Looking into this further. For the extends option to work, two things must be true:

  • The path provided must be the absolute path to the .babelrc file
  • You cannot pass presets or plugins in the same object in which you set 'extends'.

So if we modified run.js, this will not work because both presets and extends are set:

require('babel-register')({
    presets: presets,
    extends: '/Users/jim.cummins/projects/mobx-react-intro/.babelrc'
  });

And this wouldn't work because extends requires an absolute path

require('babel-register')({
    extends: './.babelrc'
  });

but this would work:

require('babel-register')({
    extends: '/Users/jim.cummins/projects/mobx-react-intro/.babelrc'
  });

So we probably need to manually check if .babelrc exists, and if it does, we pass in the absolute path to extends, if not, we fall back to the current implementation.

Sound ok?

commented

Thanks for looking into this. Your solution sounds good, I think... Can you do a PR so I can try it out? If not I may be able to try myself tomorrow when I'm a bit less busy

commented

@callumlocke Yep! Working on it now. Just documenting my brain a bit here so that in case it doesn't work you can see what I was thinking.

commented

awesome

let me know if you have questions about the build setup, it's a little unconventional (all tests get built in the same babel pipeline as the lib code)

commented

@callumlocke no worries. One quick question, in run.js, what is the best way to get the path of the user's project root. If you don't have it off the top of your head I can play around with it.

commented

Good question. Problem is there's no obvious project root. Do you mean for where we look for a .babelrc file?

Ideally we'd want to look in the dirname of the file being run, then up a directory, and so on, like how babel does it. But I'm concerned that this might confuse some users by effectively breaking esbox if they happen to have a stray .babelrc in their home directory, for example. I don't want to risk breaking the basic promise of ESBox (i.e. that it always just works with zero config) just because a user once accidentally left a .babelrc file somewhere on their filesystem. So I think it would be best to put this behaviour behind a flag, so it's just for users who know what they're doing.

How about this:

  • we imitate the --babelrc option from Babel.
  • ...except in esbox the default value should be false. Meaning, if you want to use a your own Babel config, you have to say so explicitly with esbox foo.js --babelrc.

So the behaviour in run.js would be this:

  • if the babelrc flag is false (not provided), we just use the current behaviour of passing in a optimal dynamic config.
  • if the babelrc flag is provided as a string (e.g. esbox foo.js --babelrc=some/path/to/.babelrc), we use that file.
  • if babelrc is just provided as a boolean true (i.e. esbox foo.js --babelrc), we imitate Babel's behaviour of cycling back through dirname until you find a .babelrc file.

would that work?

commented

I like it. 💯 👍

commented

Ok I got this working. One thing I think needed to be changed. Let's assume you run this command in the new system:

Working:

esbox foo.js --babelrc

Not working:

esbox --babelrc foo.js

When you think about it, this makes total sense because if --babelrc takes an optional string then in the second case, the arguments parser things that you want to pass --babelrc in with the value foo.js.

So, I propose a two part solutions:

  1. esbox --babelrc foo.js should use --babelrc as a boolean to indicate that we're going to find a babelrc based on foo.js's location.
  2. esbox --babelrc-dir ./path/to/babelrc/ foo.js would use an explicit babelrc path in the event that they want to point to an alternate location for babelrc.
  3. And finally if someone uses both, we'll favor the explicit babelrc path: esbox --babelrc --babelrc-dir ./path/to/babelrc/ foo.js

Note that with any of these options we'll just be using these paths as the starting point to use babel's findup method.

Sound ok?

(edited)

commented

Ah yeah. I think there's a convention of having a double-dash on its own to solve the problem of flags accidentally eating arguments.

Babel uses it here:

When arguments for user script have names conflicting with node options, double dash placed before script name can be used to resolve ambiguities

$ babel-node --debug --presets es2015 -- script.js --debug

I think we should just expect the user to follow this convention to resolve ambiguities (maybe we can mention it in the readme).

So the correct forms would be:

  • esbox foo.js --babelrc
  • esbox --babelrc -- foo.js
  • esbox --babelrc path/to/.babelrc foo.js

I don't think you need to do anything special to make this work, it should just work out of the box with minimist.

commented

Ok, that should hopefully do it. Added tests, usage and docs to readme. Would appreciate a quick code review.

commented

On further investigation.. It think Babel is actually supposed to use .babelrc files automatically anyway:

"You can pass in all other options as well, including plugins and presets. But note that the closest .babelrc to each file still applies, and takes precedence over any options you pass in here."
– docs

...and ESBox has actually been relying on a bug that means this doesn't work when you use the ignore option (which ESBox does). And there's a PR open for fixing this.

So something's going to break in future. Thinking about best approach

commented

Can we make the flag named babelrc-experimental?

Jim ForCy

On June 29, 2016 at 4:21:12 PM, Callum Locke (notifications@github.com)
wrote:

On further investigation.. It think Babel is actually supposed to use
.babelrc files automatically anyway:

"You can pass in all other options as well, including plugins and presets.
But note that the closest .babelrc to each file still applies, and takes
precedence over any options you pass in here."
– docs https://babeljs.io/docs/usage/require/#specifying-options

...and ESBox has actually been relying on a bug
https://phabricator.babeljs.io/T7098 that means this doesn't work when
you use the ignore option (which ESBox does). And there's a PR open
babel/babel#3291 for fixing this.

So something's going to break in future. Thinking about best approach

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#12 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AAGpihyU2-Jn48ADCLgxadn6z4vgCcmxks5qQuHIgaJpZM4H0u1o
.