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

After upgrading to the latest version of babel, I get an error: t(...).isPlaceholder is not a function #10588

Open
julienw opened this issue Oct 22, 2019 · 11 comments
Labels

Comments

@julienw
Copy link

@julienw julienw commented Oct 22, 2019

Bug Report

Current Behavior
After upgrading to latest babel packages, I get this error:

{ TypeError: /home/julien/travail/git/perf.html/src/index.js: t(...).isPlaceholder is not a function
    at placeholderVisitorHandler (/home/julien/travail/git/perf.html/node_modules/@babel/core/node_modules/@babel/template/lib/parse.js:81:11)
    at traverseSimpleImpl (/home/julien/travail/git/perf.html/node_modules/@babel/core/node_modules/@babel/template/node_modules/@babel/types/lib/traverse/traverse.js:27:14)
    at Object.traverse (/home/julien/travail/git/perf.html/node_modules/@babel/core/node_modules/@babel/template/node_modules/@babel/types/lib/traverse/traverse.js:21:3)
    at parseAndBuildMetadata (/home/julien/travail/git/perf.html/node_modules/@babel/core/node_modules/@babel/template/lib/parse.js:65:7)
    at buildLiteralData (/home/julien/travail/git/perf.html/node_modules/@babel/core/node_modules/@babel/template/lib/literal.js:53:35)
    at literalTemplate (/home/julien/travail/git/perf.html/node_modules/@babel/core/node_modules/@babel/template/lib/literal.js:20:7)
    at Function.ast (/home/julien/travail/git/perf.html/node_modules/@babel/core/node_modules/@babel/template/lib/builder.js:52:42)
    at Object.ast (/home/julien/travail/git/perf.html/node_modules/@babel/core/node_modules/@babel/helpers/lib/helpers.js:26:42)
    at fn (/home/julien/travail/git/perf.html/node_modules/@babel/core/node_modules/@babel/helpers/lib/index.js:248:30)
    at loadHelper (/home/julien/travail/git/perf.html/node_modules/@babel/core/node_modules/@babel/helpers/lib/index.js:251:40) code: 'BABEL_TRANSFORM_ERROR' }

Input Code

import something from 'something';

with such .babelrc:

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

Environment

  • Babel version(s): core is 7.6.4, template is 7.6.0, types is 7.6.3
  • Node/npm version: node v10.16.3
  • OS: Linux
  • Monorepo: no
  • How you are using Babel: cli in this case, but the problem happened first with my webpack configuration

Note:
I use yarn and I took care that the subdependencies where the problem seems to happen (types, template, core) used latest version.

@babel-bot

This comment has been minimized.

Copy link
Collaborator

@babel-bot babel-bot commented Oct 22, 2019

Hey @julienw! We really appreciate you taking the time to report an issue. The collaborators on this project attempt to help as many people as possible, but we're a limited number of volunteers, so it's possible this won't be addressed swiftly.

If you need any help, or just have general Babel or JavaScript questions, we have a vibrant Slack community that typically always has someone willing to help. You can sign-up here for an invite."

@JLHwung

This comment has been minimized.

Copy link
Contributor

@JLHwung JLHwung commented Oct 22, 2019

The @babel/* dependencies are not flatten to the root level, as a workaround, please run

yarn-deduplicate yarn.lock --packages @babel/types

or for those npm users

npm --depth 9999 update @babel/types

Could you offer the yarn.lock (pre-upgrade / post-upgrade)? We would investigate why yarn does not hoist them to the root level.

@julienw

This comment has been minimized.

Copy link
Author

@julienw julienw commented Oct 22, 2019

I did the same process manually before filing the bug (thanks for the tool, much easier!). So I still have it after running the same process with the tool. I also did it for @babel/core and @babel/template.
but I don't have the problem when doing it on everything. So likely one of the other modules is the problem.

And now I can't reproduce anymore, probably because my node_modules is in a better shape :)
Ths isn't really encouraging that a same pair package.json/yarn.lock doesn't bring the same node_modules :/

@JLHwung

This comment has been minimized.

Copy link
Contributor

@JLHwung JLHwung commented Oct 22, 2019

If the shape of node_modules are changed by yarn, yarn.lock must also be changed otherwise it is a bug.

yarn-deduplicate writes the new yarn.lock but does not touch node_modules. And I assume you have run yarn after that. So the yarn.lock must experience the following process

old version  ===>  yarn update  ===>  yarn-deduplicate
( good )            ( bad )              ( good )  

Could you share the yarn.lock of the first (good) and (bad)? You may also DM me on slack. We would like to make sure if there is anything wrong on babel's side.

@julienw

This comment has been minimized.

Copy link
Author

@julienw julienw commented Oct 22, 2019

Actually I could reproduce again by 1/ switching to master and running yarn install, then 2/ switching to my branch and running yarn install.

By using yarn-deduplicate on various babel packages I could determine that the problem was with @babel/code-frame. Does that mean that some other babel package should require a newer version of that package?

@julienw

This comment has been minimized.

Copy link
Author

@julienw julienw commented Oct 22, 2019

  1. before upgrade
  2. bad when installing on top of the previous one, good when installing on top of the next one. You'll see that I upgraded more than just babel stuff here. It's a bit strange that I don't get the same behavior depending on which previous yarn.lock we had, but maybe not that strange because package.json changes too between 1 and 2 (but not between 2 and 3)
  3. always good, after deduplicating @babel/code-frame only.

This is the main difference between the 2nd and the 3rd:

-"@babel/code-frame@^7.0.0":
-  version "7.0.0"
-  resolved "https://registry.yarnpkg.com/@babel/code-frame/-/code-frame-7.0.0.tgz#06e2ab19bdb535385559aabb5ba59729482800f8"
-  integrity sha512-OfC2uemaknXr87bdLUkWog7nYuliM9Ij5HUcajsVcMCpQrcLmtxRbVFTIqmcSkSeYRBFBRxs2FiUqFJDLdiebA==
-  dependencies:
-    "@babel/highlight" "^7.0.0"
-
-"@babel/code-frame@^7.5.5":
+"@babel/code-frame@^7.0.0", "@babel/code-frame@^7.5.5":
   version "7.5.5"
   resolved "https://registry.yarnpkg.com/@babel/code-frame/-/code-frame-7.5.5.tgz#bc0782f6d69f7b7d49531219699b988f669a8f9d"
   integrity sha512-27d4lZoomVyo51VegxI20xZPuSHusqbQag/ztrBC7wegWoQ1nLREPVSKSW8byhTlzTKyNE4ifaTA6lCp7JjpFw==
   dependencies:
     "@babel/highlight" "^7.0.0"

(plus yarn-deduplicate and its dependencies obviously)

Hope that helps!

@JLHwung

This comment has been minimized.

Copy link
Contributor

@JLHwung JLHwung commented Oct 22, 2019

@nicolo-ribaudo In 7.5.5, @babel/core bumps @babel/code-frame dependencies to ^7.5.5, but @babel/template remain the dependency on ^7.0.0 because there is no change in @babel/template.

This dependency inconsistency results in nested dependencies in node_modules. Should we also bump the version of dependents of lerna changed?

@JLHwung

This comment has been minimized.

Copy link
Contributor

@JLHwung JLHwung commented Oct 22, 2019

@julienw What's the version of @babel/types in ./node_modules/@babel/core/node_modules/@babel/template/node_modules/@babel/types/package.json? If it is exactly 7.6.x, then isPlaceholder is well defined and it may be caused by uninitialized commonjs module, otherwise it should be a bug of yarn.

@julienw

This comment has been minimized.

Copy link
Author

@julienw julienw commented Oct 22, 2019

I get 7.3.0 for that one.

@julienw

This comment has been minimized.

Copy link
Author

@julienw julienw commented Oct 22, 2019

I agree that it could be a bug of yarn because we don't get the same setup with the same package.json/yarn.lock depending the environment we come from... (EDIT: given yarn doesn't generate a new yarn.lock I believe this means that it fullfils properly the requirements from package.json)

@nicolo-ribaudo

This comment has been minimized.

Copy link
Member

@nicolo-ribaudo nicolo-ribaudo commented Oct 22, 2019

@nicolo-ribaudo In 7.5.5, @babel/core bumps @babel/code-frame dependencies to ^7.5.5, but @babel/template remain the dependency on ^7.0.0 because there is no change in @babel/template.

This dependency inconsistency results in nested dependencies in node_modules. Should we also bump the version of dependents of lerna changed?

If it will make it less likely to have problems like this, then yes 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.