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

[preset-env] Android not supporting anything? #8351

Closed
luzat opened this issue Jul 20, 2018 · 10 comments
Closed

[preset-env] Android not supporting anything? #8351

luzat opened this issue Jul 20, 2018 · 10 comments
Labels
outdated A closed issue/PR that is archived due to age. Recommended to make a new issue

Comments

@luzat
Copy link

luzat commented Jul 20, 2018

Bug Report

The preset seems to think that Android does not support anything and enables every plugin because of "android": "67" support. Chrome for Android should support most features in that version.

I set up an example repository with basic configuration and debug enabled. Output after npm install/yarn install and npm run demo/yarn run demo is:

> babel-preset-env-demo@1.0.0 demo /home/tom/p/babel-preset-env-demo
> babel index.js

@babel/preset-env: `DEBUG` option

Using targets:
{
  "android": "67",
  "chrome": "66",
  "edge": "17",
  "firefox": "60",
  "ios": "11",
  "safari": "11.1"
}

Using modules transform: commonjs

Using plugins:
  transform-template-literals { "android":"67" }
  transform-literals { "android":"67" }
  transform-function-name { "android":"67", "edge":"17" }
  transform-arrow-functions { "android":"67" }
  transform-block-scoped-functions { "android":"67" }
  transform-classes { "android":"67" }
  transform-object-super { "android":"67" }
  transform-shorthand-properties { "android":"67" }
  transform-duplicate-keys { "android":"67" }
  transform-computed-properties { "android":"67" }
  transform-for-of { "android":"67" }
  transform-sticky-regex { "android":"67" }
  transform-dotall-regex { "android":"67", "edge":"17", "firefox":"60", "ios":"11" }
  transform-unicode-regex { "android":"67" }
  transform-spread { "android":"67" }
  transform-parameters { "android":"67" }
  transform-destructuring { "android":"67", "edge":"17" }
  transform-block-scoping { "android":"67" }
  transform-typeof-symbol { "android":"67" }
  transform-new-target { "android":"67" }
  transform-regenerator { "android":"67" }
  transform-exponentiation-operator { "android":"67" }
  transform-async-to-generator { "android":"67" }
  proposal-async-generator-functions { "android":"67", "edge":"17", "ios":"11", "safari":"11.1" }
  proposal-object-rest-spread { "android":"67", "edge":"17", "ios":"11" }
  proposal-unicode-property-regex { "android":"67", "edge":"17", "firefox":"60", "ios":"11" }

Using polyfills: No polyfills were added, since the `useBuiltIns` option was not set.
"use strict";

I would expect the Android browser to support most if not all of these. I guess there is a mapping from Android to the equivalent Chrome versions missing at some point (compat-table, caniuse, browserslist?) and I recall having used Babel 7 previously without this behavior. I imagine some third-party library update to be responsible.

babel.config.js

module.exports = {
  presets: [
    [
      '@babel/env',
      {
        debug: true,
      },
    ],
  ],
}

I am not sure if the feature sets of Android x and Chrome x are equivalent starting with some version of if there are numbering and feature differences to account for, but probably either compat-table or preset-env should have some mapping., most likely for all versions of Android >4.4.

Environment

  • Babel version(s): 7.0.0-beta.54; downgrading to beta.31 did not help.
  • Node/npm version: Node v10.7.0
  • OS: Debian GNU/Linux
  • How you are using Babel: cli and loader
@babel-bot
Copy link
Collaborator

Hey @luzat! 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.

@existentialism
Copy link
Member

existentialism commented Jul 20, 2018

I recall having used Babel 7 previously without this behavior

Hmm, not sure as compat-table only has explicit handling of android <= 4.4.3, and removed the Chrome aliases for a while now:

compat-table/compat-table#1104

My initial reaction is I'd rather keep it (relatively) simple and consistent with our data source (compat-table), and ask users to use Chrome, than maintain a mapping.

We should do better about documenting this, for sure!

EDIT: Maybe if we get a target of android >4 we can show a message to use Chrome instead?

@luzat
Copy link
Author

luzat commented Jul 20, 2018

It is very non-intuitive if specifying Android as a platform includes all plugins/transforms without explanation. Also, other tools might require Android to be in the browser list, which would lead to maintaining multiple lists for different tools.

There is already special code for Opera and Electron, too, which could be removed with the same reasoning.

Looking at the version history it seems that after 4.4, starting with Chrome 18, the same engine has always been used. The code next to Opera's and Electron's code can probably be easily extended (the check for plugin.android is necessary to avoid overwriting a possible value of 4.4, 4.1 or similar which might have been set previously):

// add android
if (!plugin.android && plugin.chrome >= 18) {
  plugin.android = plugin.chrome;
}

Untested; but it looks as if this could suffice?

@existentialism
Copy link
Member

existentialism commented Jul 20, 2018

I guess I view Android 67 a bit differently than Opera 67 or Electron 67... since Android 67 doesn't exist? It's Chrome for Android v67... while it might be pedantic; since we haven't had any complaints about this, I'm a bit hesitant to introduce this change.

@luzat
Copy link
Author

luzat commented Jul 20, 2018

I need to think a bit about this. caniuse knows about Android browsers <=4.4 and Android 67 (with global usage of 0), which I think are encoded as "android". Chrome for Android should be encoded as and_chr, currently at 67, too. For some reason browserslist does not return and_chr 67, but android 67. This could be the root cause. and_chr would be mapped to chrome by preset-env.

This may be a bug in some of the other components (browserslist?) which my repository above can be used for to reproduce. Basically, a query to browserslist with >1% should include and_chr 67, not android 67. I will try to look into this, but if somebody could confirm that android is falsely returned, that would be helpful.

@luzat
Copy link
Author

luzat commented Jul 20, 2018

I have to correct myself: "last 1 version" introduces android 67, but also includes and_chr 67. caniuse always (at least for some time) adds the current Chrome for Android browser as the current Chromium version with usage equal to 0: "Starting in Android 5, the web engine can be updated separately, so the latest Chromium version number is used instead." That's of course a bit weird, but this shouldn't be passed onto users of preset-env.

Given that browserslist recommends to include "last 1 version" in its "Best Practices", this means that most users will get "android 67" included and in turn most transforms (often without noticing). Given that Chromium x should support the same features as Chrome for Android x from what I know, the patch still seems to make sense versus requiring all users who use a recommended configuration to read a notice and exclude a browser which would in reality support those features. The point of preset-env is mostly interpreting mapping browser data to features, which is why I think this belongs to its core functionality and not into a user's configuration. I also don't think one could convince caniuse or browserslist to change their behavior in that case given the number of dependencies they have (and how data is used on caniuse.com). Explaining why people need "not android > 0" (or >= 5/>=18) feels more weird to me than mapping/copying android >=18 to chrome, but I'll leave it at that.

@jhuesos
Copy link

jhuesos commented Dec 12, 2018

I just faced this issue as well. If I add last 2 Android major versions to my target, android 67 is added to the target. And if I do that, everything gets compiled to ES5, even though according to https://caniuse.com/#feat=es6-class, Android 67 supports ES6 Classes.

@stefanprobst
Copy link

This is especially problematic because the browserslist defaults include Android 67:

$ npx browserslist defaults | grep -i android
android 67
android 4.4.3-4.4.4

@melfa
Copy link

melfa commented Feb 26, 2020

Any updates on this? browserslist defaults still returns android 76, preset-env with debug enabled reports "android": "4" and compiles all to ES5.

% npx browserslist defaults
and_chr 79
and_ff 68
and_qq 1.2
and_uc 12.12
android 76
baidu 7.12
chrome 79
chrome 78
chrome 49
edge 18
edge 17
firefox 72
firefox 71
firefox 70
firefox 68
ie 11
ios_saf 13.3
ios_saf 13.2
ios_saf 13.0-13.1
ios_saf 12.2-12.4
kaios 2.5
op_mini all
op_mob 46
opera 64
opera 63
safari 13
safari 12.1
safari 5.1
samsung 10.1
samsung 9.2
@babel/preset-env: `DEBUG` option

Using targets:
{
  "android": "80",
  "chrome": "4",
  "edge": "18",
  "firefox": "71",
  "ios": "11.3",
  "opera": "65",
  "safari": "13"
}

@JLHwung
Copy link
Contributor

JLHwung commented Feb 26, 2020

This issue has been fixed in #10814, please update @babel/preset-env to 7.8.4 or above.

@JLHwung JLHwung closed this as completed Feb 26, 2020
@github-actions github-actions bot added the outdated A closed issue/PR that is archived due to age. Recommended to make a new issue label May 28, 2020
@github-actions github-actions bot locked as resolved and limited conversation to collaborators May 28, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
outdated A closed issue/PR that is archived due to age. Recommended to make a new issue
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants