Skip to content
This repository has been archived by the owner on Feb 19, 2022. It is now read-only.

BUG: .babelrc is not explicitly pointed to everywhere, sometimes doesn't get used #4

Closed
exogen opened this issue Nov 4, 2015 · 6 comments · Fixed by FormidableLabs/victory-component-boilerplate#12
Labels

Comments

@exogen
Copy link
Contributor

exogen commented Nov 4, 2015

As @boygirl found in FormidableLabs/victory-component-boilerplate#11, using the @Radium syntax in the new Builder-based victory-component-boilerplate doesn't work, because Babel isn't always getting its config from our .babelrc and thus uses the default settings.

With decorator syntax, this uses the correct .babelrc and works: builder run build-lib

These do NOT work: builder run build-dist and builder run test-frontend

Addng .babelrc to ROOT makes it work, but we don't want to have to do that.

We need a way to pass along our .babelrc path to Webpack (for building dist and testing) and isparta (for coverage) – the latter probably being the most difficult as I don't think an option is exposed.

/cc @ryan-roemer @boygirl

@ryan-roemer
Copy link
Member

Yep. Makes sense. I'm looking into this.

@exogen
Copy link
Contributor Author

exogen commented Nov 4, 2015

There's this outstanding pull request: babel/babel-loader#121

Note that I tried putting .babelrc in the root of builder-react-component already and that didn't work – even though babel/babel#1886 claims that .babelrc is resolved relative to the input file it's transpiling (if that were the case, it seemed like putting it in builder-react-component root should work...). EDIT: Nevermind, forgot that it's transpiling files outside of builder-react-component...

@exogen
Copy link
Contributor Author

exogen commented Nov 4, 2015

Unless we get some pull requests on some third-party projects merged, or do some kind of path trickery, it's looking to me like custom .babelrc paths aren't well supported enough at the moment by Babel-ecosystem libraries. We could switch to using query for babel-loader, but I think that doesn't solve isparta as they removed the option to pass along Babel options last I checked.

Note that Babel has a BABEL_ENV environment variable (which then uses a certain config in your .babelrc), but not an environment variable for the .babelrc path itself.

@ryan-roemer
Copy link
Member

Ugh. Reading up, this comports with my evolving understanding...

@boygirl / @exogen -- Can we:

  • Add a section in the README.md in this archetype saying "need ROOT/.babelrc" and a link to this issue.
  • Add a .babelrc to formidable-react-component-boilerplate and victory-boilerplate

... in the meantime?

@ryan-roemer ryan-roemer added the bug label Nov 4, 2015
@ryan-roemer ryan-roemer changed the title .babelrc is not explicitly pointed to everywhere, sometimes doesn't get used BUG: .babelrc is not explicitly pointed to everywhere, sometimes doesn't get used Nov 4, 2015
@exogen
Copy link
Contributor Author

exogen commented Nov 4, 2015

@ryan-roemer 👍 Can do. I think we should remove --babelrc from this archetype too in the meantime, so it's always using the same config, otherwise stuff might get weird.

@ryan-roemer
Copy link
Member

@exogen -- Agreed. Thanks!

exogen added a commit that referenced this issue Nov 4, 2015
This removes `--babelrc` and will require boilerplates and other
projects using this archetype to add their own `.babelrc` if they
want non-default settings.

This PR does not remove the actual `.babelrc` file in this repo – it's
not hurting anything, can be used as a reference, and will most likely
be used again later when custom babelrc is more widely supported.

Reference: #4 (not yet fixed)

/cc @boygirl @ryan-roemer
exogen added a commit to FormidableLabs/victory-component-boilerplate that referenced this issue Nov 4, 2015
This adds a .babelrc until we can resolve
FormidableLabs/builder-react-component#4. Since stage 0 is now being
used as intended, bring back `@Radium`.

/cc @ryan-roemer @boygirl
exogen added a commit to FormidableLabs/formidable-react-component-boilerplate that referenced this issue Nov 4, 2015
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants