babel: Module build failed: TypeError: Cannot read property 'loose' of undefined

Help!! I got a problem while building a test demo, it said “Module build failed: TypeError: Cannot read property 'loose' of undefined...

Here are some configs: webpack.production.config :

{
    "devDependencies": {
        "babel-preset-env": "^7.0.0-beta.3"
     }
}

.babelrc :

{ "presets": ["env"]}

what should I do now ? is there any dependency I forgot to install?

About this issue

  • Original URL
  • State: closed
  • Created 7 years ago
  • Reactions: 13
  • Comments: 24 (9 by maintainers)

Commits related to this issue

Most upvoted comments

Tossing my hat into the ring. Getting the same error about loose.

  "devDependencies": {
    "@babel/cli": "^7.0.0-beta.36",
    "@babel/core": "^7.0.0-beta.36",
    "@babel/preset-env": "^7.0.0-beta.36"
}

And my .babelrc

{
  "presets": ["@babel/preset-env", {
    "targets": {
      "browsers": ["last 2 versions"]
    }
  }]
}

Running a simple $ babel client.js command. Produces the same error as others have listed above:

TypeError: Cannot read property 'loose' of undefined (While processing preset: "/Users/.../node_modules/@babel/preset-env/lib/index.js")
    at _default (/Users/.../node_modules/@babel/plugin-transform-modules-commonjs/lib/index.js:21:23)

If you are getting Cannot read property 'loose' of undefined you probably have an mismatched version in package-lock/yarn.lock due to ^? Also in your babelrc you need to wrap the preset in [] like

{
  "presets": [
    ["@babel/preset-env", {
      "targets": {
        "browsers": ["last 2 versions"]
      }
    }]
  ]
}

otherwise you have 2 presets

Can we not do anything to fix this? keep getting this coming up - I guess mostly because users don’t know what to actually change

For Babel 7.x:

Preset:- @babel/preset-env In .babelrc

{
  "presets": ["@babel/preset-env"]
}

For Babel 6.x:

Preset:- babel-preset-env In .babelrc

{
  "presets": ["env"]
}

also had this issue until i upgraded to babel-loader ^8.0.0

from the babel-loader repo:

webpack 3.x | babel-loader 8.x | babel 7.x

npm install babel-loader@8.0.0-beta.0 @babel/core @babel/preset-env webpack

webpack 3.x babel-loader 7.x | babel 6.x

npm install babel-loader babel-core babel-preset-env webpack

For anyone experiencing this issue while using Jest with babel 7.x, installing the below fixed this issue for me: babel-jest 'babel-core@^7.0.0-0' @babel/core regenerator-runtime

Taken from the Jest docs: https://github.com/facebook/jest#using-babel

I’m going to close this issue since there isn’t anything actionable in the issue itself. Do know that we absolutely get that this is a pain point for users, and we’ll likely be putting in some logic to throw a more helpful error. It’ll still be an error though. If you have questions you can still feel free to post, but do understand that we’re likely going to focus more on trying to finish 7.x itself.

If you’re getting this error it is always because you have Babel 6 somewhere that should be using Babel 7. Usually that means either

  1. You haven’t configured one of your tools to load Babel 7
  2. One of your tools is hard-coded to Babel 6 and doesn’t offer a way to configure it.

Either way you have to do some debugging. If you want to debug the issue, the first step would be to look at the stack trace of the error. It will mention babel-core instead of @babel/core on one of the lines in the trace. You might also be able to see what is calling Babel in the first place, depending on how long the trace is. Beyond that, look at node_modules, look for references to babel-core and unless they are loading babel-core@7.0.0-bridge.0, that is probably the source of the issue.

I get this issue as well but also many others that I don’t get with babel v6.

I know babel 7 is in beta but we either need more helpful error messages or more sane defaults or dependencies. People are going to be frustrated and look elsewhere.

@hzoo webpack-cli depends on babel-core as @babel/core is not yet stable. Any project using webpack-cli is going to run into this problem when trying to use @babel/anything. What’s the limitation here and what needs to happen to get a fix in babel for it?

after chatting with @loganfsmyth the issue was moreso a conflict of babel 6 persisted on my machine trying to run the babel 7 preset. It was his conclusion that the babel 7 plugins should be updated to assert they’re not being used by a lesser version.

I’ve simplified my .babelrc as much as I could:

{
  "plugins": [

  ],
  "presets": [
    [
      "@babel/preset-env",
      {
        "targets": {
          "browsers": "last 2 chrome versions"
        }
      }
    ]
  ],
  "compact": false
}

And removed all the ^s from package.json just to be sure:

  "devDependencies": {
    "@babel/cli": "7.0.0-beta.38",
    "@babel/core": "7.0.0-beta.38",
    "@babel/plugin-proposal-class-properties": "7.0.0-beta.38",
    "@babel/plugin-proposal-function-bind": "7.0.0-beta.38",
    "@babel/plugin-proposal-object-rest-spread": "7.0.0-beta.38",
    "@babel/plugin-syntax-jsx": "7.0.0-beta.38",
    "@babel/plugin-transform-react-display-name": "7.0.0-beta.38",
    "@babel/plugin-transform-react-jsx": "7.0.0-beta.38",
    "@babel/plugin-transform-react-jsx-self": "7.0.0-beta.38",
    "@babel/plugin-transform-react-jsx-source": "7.0.0-beta.38",
    "@babel/preset-env": "7.0.0-beta.38",
    "autoprefixer": "^7.2.5",
    "babel-loader": "^8.0.0-beta.0",
    "file-loader": "^1.1.6",
    "lodash": "^4.17.4",
    "react": "^16.2.0",
    "react-dom": "^16.2.0",
    "react-hot-loader": "^3.1.3",
    "styled-components": "^3.0.2",
    "svg-url-loader": "^2.3.1",
    "url-loader": "^0.6.2",
    "webpack": "^3.10.0",
    "webpack-dev-server": "^2.11.1"
  }

Deleted node_modules and yarn.lock and reinstalled.

babel-core does not appear in yarn.lock, only @babel/core.

Still getting this

Cannot read property ‘loose’ of undefined (While processing preset: “/home/me/project/node_modules/@babel/preset-env/lib/index.js”)

I give up. Going back to Babel 6.

“babel-preset-env”: “^7.0.0-beta.3”

The beta at this point has moved to @babel/preset-env and if you want to use the beta, you’ll need to use Babel 7. This error implies that you are using Babel 6 to load this plugin, which is meant for 7.x.

Thanks a lot @loganfsmyth Adding @babel/register explicitly fixed the problem for me 😄 I didn’t find anything else that suggested that. Updated dependencies:

"dependencies": {
  "@babel/cli": "^7.0.0-beta.40",
  "@babel/core": "^7.0.0-beta.40",
  "@babel/preset-env": "^7.0.0-beta.40",
  "@babel/register": "^7.0.0-beta.40",
  "babel-loader": "^8.0.0-beta.0",
  "webpack": "^4.1.1",
  "webpack-cli": "^2.0.11",
  "webpack-validator": "^3.0.0"
}

@gpspake The stack trace mentions babel-register which is Babel 6. It would be @babel/register for Babel 7.

We must use the babel-loader version >7

It seems jscodeshift@^0.4.0 uses babel-register "^6.9.0" and babel-core "^6.26.0" jscodeshift is used by webpack-cli

using the following config

"dependencies": {
    "react": "^16.2.0",
    "react-dom": "^16.2.0"
  },
  "devDependencies": {
    "@babel/core": "^7.0.0-beta.40",
    "@babel/preset-env": "^7.0.0-beta.40",
    "@babel/preset-flow": "^7.0.0-beta.40",
    "@babel/preset-react": "^7.0.0-beta.40",
    "babel-loader": "^7.1.3",
    "html-webpack-plugin": "webpack-contrib/html-webpack-plugin",
    "webpack": "^4.0.1",
    "webpack-cli": "^2.0.9"
  },
  "babel": {
    "presets": [
      "@babel/preset-env",
      {
        "targets": {
          "browsers": [
            "last 2 versions",
            "safari >= 7"
          ]
        }
      }
    ]
  }

what is the way forward? Do I need to raise an issue in webpack-cli repo or jscodeshift repo ?

@shellscape I don’t know that I can give a timeline because no matter what I feel like it’ll be wrong, but I’ve filed https://github.com/babel/babel/issues/7265 for it and I would consider it a high priority. The only reason I didn’t just do it when we talked was because I want to make sure the approach is as future-proof as possible so this doesn’t just happen again as we evolve the plugin APIs over time.