Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

chore(package): update babel to version ^7.5.5 #179

Closed

Conversation

emanualjade
Copy link

Description

Update from Babel v6 to Babel v7

Following package updates

  • @babel/cli@^7.5.5
  • @babel/core@^7.5.5
  • @babel/plugin-transform-object-assign@^7.2.0
  • @babel/preset-env@^7.5.5
  • @babel/register@^7.5.5
  • @babel-eslint@^10.0.2

** index.js **

  • Uses the v7 version @babel/register rather than the v6 babel-register

The rationale is that most new projects start with Babel 7 and there are potential conflicts with babel versions.

@emanualjade
Copy link
Author

@mrsteele curious what you think about upgrading to Babel 7

@codecov
Copy link

codecov bot commented Aug 4, 2019

Codecov Report

Merging #179 into master will not change coverage.
The diff coverage is n/a.

Impacted file tree graph

@@           Coverage Diff           @@
##           master     #179   +/-   ##
=======================================
  Coverage   98.57%   98.57%           
=======================================
  Files           1        1           
  Lines          70       70           
=======================================
  Hits           69       69           
  Misses          1        1
Impacted Files Coverage Δ
src/index.js 98.57% <0%> (ø) ⬆️

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 c728f87...7525b23. Read the comment docs.

@mrsteele
Copy link
Owner

mrsteele commented Aug 4, 2019

This is just a chore update (which it probably should be). Are there any breaking changes?

@emanualjade
Copy link
Author

emanualjade commented Aug 4, 2019

Yeah it's just a chore.

As far as breaking changes go this may be considered a breaking change.

  • User is using Babel v6 for a variety of things in their development
  • User upgrades dotenv-webpack to the latest version that uses Babel v7
  • Users babel command has two conflicting babel packages in their repo.

The breaking change is more about the users configuration but should probably be considered breaking?

@mrsteele
Copy link
Owner

mrsteele commented Aug 4, 2019

I think something interesting about all of this is that these are dev dependencies. Should versions be conflicting like they are? This dependency version of Babel shouldn’t be used in your main project.

@emanualjade
Copy link
Author

emanualjade commented Aug 4, 2019

I think you're right and I assumed the same. Some issues have come up that may be related to our own config. I'll explain though just in case it's relevant.

The problem in a nutshell

  • Using Yarn + Next.js
  • Installed dotenv-webpack as a dependency = 👍
  • In dev mode on local machine everything works well = 👍
  • Deploy code to production and it's great = 👍
  • Install storybook npm package in devDependencies and all is great on local dev mode = 👍
  • Attempt to deploy again and this where things fail. = 😢
Error: Cannot find module 'babel-register'      
at Function.Module._resolveFilename (internal/modules/cjs/loader.js:636:15)      
at Function.Module._load (internal/modules/cjs/loader.js:562:25)      
at Module.require (internal/modules/cjs/loader.js:690:17)      
at require (internal/modules/cjs/helpers.js:25:18)      
at Object.<anonymous> (/srv/node_modules/dotenv-webpack/index.js:8:5)      
at Module._compile (internal/modules/cjs/loader.js:776:30)      
at Object.Module._extensions..js (internal/modules/cjs/loader.js:787:10)      
at Module.load (internal/modules/cjs/loader.js:653:32)      
at tryModuleLoad (internal/modules/cjs/loader.js:593:12)      
at Function.Module._load (internal/modules/cjs/loader.js:585:3)

The failure happens even though the code has not changed. It was just the storybook package installation itself that causes the difference.

I started speculating that because deployment did work before that there must be a conflict with babel versions. Unfortunately what happens after deployment is a blackbox so I've been trying different things to see if it is a babel issue or a deployment issue.

Mostly been attempting things with babel-bridge which is meant to resolve babel 6 to 7 issues.
https://github.com/babel/babel-bridge

The other thing I've been trying is using resolutions with babel-bridge as discussed in an unrelated thread here
jestjs/jest#6913

Having these unresolved issues is why I thought
A: A babel upgrade may be a breaking change
B: I should clarify why I ended up making the PR to upgrade to babel 7

The thing that sticks out to me a bit is seeing the babel-register issue at all looks like we're not using the code from dist but somehow using the code from the main package. Not certain what's happening here.

I have more investigating to do but my current bugs seem worth mentioning in relation to the PR

Might be worth noting that in the yarn.lock I notice storybook is also using dotenv-webpack

@emanualjade
Copy link
Author

@mrsteele
Follow up from my last comment. After unsuccessfully attempting to replicate my issues in a local dev environment it seems the issues are with our own production build and configuration and not the babel setup.

Final thoughts about everything In relation to this PR

  • Is updating babel in this PR a breaking change? It seems not.
  • I personally like your other PR chore: removing babel #161 that removes Babel better but an upgrade would't hurt if you're looking to support old versions of node.

@mrsteele
Copy link
Owner

This has been finished. Closing.

@mrsteele mrsteele closed this Jul 16, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants