Question: Supports browserslist config on package.json?

[amilajack]

Does this plugin allow using the browserslist property in the package.json?

[yavorsky]

@amilajack Yes! I'm going to implement this tomorrow!
Today I've made the presentation for a small meetup and thought - "Why we still don't implement this?"🤔 on a slide about common config for preset-env/autoprefixer/eslint-compat.
We just need to update autoprefixer to ^1.5 and ensure that browserslist doesn't return default browsers if we are not specifying browsers in targets.

[amilajack]

🎉🎉🎉 Would play very nicely with eslint-plugin-compat

[ai]

@yavorsky why you don’t want to use default browsers set if browsers was not specified?

Browserslist default is a good set. Also using default set is a Autoprefixer behaviour right now. We need to change it too if there is some problem with it.

[yavorsky]

@ai the idea is to use babel-preset-env without any options like babel-preset-latest. It must be easy to switch from latest preset or just 2015 to env without risks and losses. Also, users need to remember the set of default browsers to know what they actually support.
As I see, with default set, some builtIns won't be included so it might be confusing for people who are not using any option and expecting all things to include.

[ai]

@yavorsky OK, I understand logic. But sad that in result Autoprefixer and babel-preset-env will be different :(.

Also in my experience users should not set browsers. Most of users make a mistake in setting browsers. A lot of users will set browserslist: 'last 2 iOS versions' for mobile website. We already saw a lot of problems with it and -webkit- prefix.

This is why main way to use Autoprefixer is to no set browsers. Because default browsers is better for most of users.

What do you think about it? Maybe babel-preset-env should not force users to set browsers too, because they will make mistakes in it?

[yavorsky]

@ai Yes, I like simplicity too and this preset is a good intention. As autoprefixer/browserslist of course.
But there are some issues:

1. What criteria of selecting default browsers? Why ie 10 or chrome 49 are in default list?
2. Default list could be changed in the future (or no? 🤔) , so it could broke something if, for ex, I need to support firefox 45 and then it was removed from the list.
3. We must provide an easy way for switching from latest preset to env. Even if you are not ready to set targets you already safe to use env.
4. I predict many issues from people who may support node 0.12 or browsers not so green as all we want with plugins/built-ins absence and our answers pointing to default browsers list and explaining that they need to specify node 0.12 directly in config because it's not part of the defaults.

Attempt to simplify could cause complication. The default list is a real list of all items we must know about. Need to think more about it 🙃

[existentialism]

default[ing to a] browsers list and explaining that they need to specify node 0.12 directly in config because it's not part of the defaults.

This and the rest of the issues @yavorsky mentions above are valid. (Especially since we seem to have received a healthy mix of issues from both node and browser users 😜)

Seems like mimicking autoprefixer's default browser behavior would only work if we had some sort of clear signal that the user is targeting browser(s)? And if they're giving us some flag, it winds up not being much more work to go ahead and set their targets?

[ai]

@yavorsky Default browsers query: > 1%, last 2 versions, Firefox ESR.

• > 1% means that all popular browsers will be in list.
• last 2 versions is Google browsers strategy.
• Firefox ESR for enterprise users.

Note, that we force users to not focused on direct versions in browsers (like chrome 52) query and force them to use dynamic queries (last 2 version).

This list is result of long discussion in Autoprefixer.

Default browsers query could be changed. We change it few times. But because it based on dynamic queries, we really don’t need to change it often.

[ai]

@yavorsky Also we could add some node version in default query. Unfortunately, @hzoo continue to ignore me :(. So he didn’t answer on any of my question about node support in Browserslist and I feel a little uncomfortable with it :(.

We could add node LTS query that will select all supported node.js version (4, 6, 7 right now). What do you think about it?

[yavorsky]

@ai You could be more persistent. 😄

Yes, it's interesting! But it isn't resolve 3 and 4 issues. It brokes the idea that preset-env without configuration is preset-latest anyway.
Maybe it's ok that autoprefixer and env behavior will be different. autoprefixer must support more things on the lowest browsers' versions, but for env it's only ~4 built-ins from ie 10 to ie 6 🤔
I think default list is a good thing in general, but it's really unsafe for the transition period. The period when people can easy select env in favor of preset-latest or preset-es2015.

I really like to see more thoughts on this issue. We could implement it in 5 minutes, but then all days long resolve issues mentioned in option 4.

[ai]

@yavorsky :D I am at Sri Lanka right now :D

I agree that preset-env without configuration is preset-latest is good idea. But I forgot to tell that I think it is short-term over long-term. Your users will be happy right now. But because you will force them to set browsers manually, they will set them in wrong way. I am sure, that most of mobile website developers will set something like last 2 iOS versions and it brings us back to -webkit- hell.

But let’s think for some solution to fix both our problems:

1. We could bring some migration tool or just docs to ask users create a browserslist key in package.json with preset-latest defaults.
2. We could increase browserslist defaults to cover preset-latest defaults. Anyway I think to release a major update in next month.

[amilajack]

Off topic: I'm Sri Lankan! 😂

[exarus]

Hello.
Off topic: I'm half Sri Lankan! Half Russian.
Any updates on this?

[ai]

@yavorsky what workaround we have foe this? babel-preset-env will not find config automatically, because without browsers option, it will use es2015 settings.

Maybe we should add browserslist: true option? In case of this option, babel-preset-env will use browserslist even without browsers option?

[yavorsky]

@ai @exarus Sorry for the delay.

1. env converts targets to browserslist query.
2. Sets it as defaults (needed to prevent browserslist defaults and use targets)
3. browserslist reads for browserslist query passed as 1-st argument.
4. browserslist searches for config/field in pacakge.json
5. we merging targets and browserslist results where browserslist targets have higher priority.

So,

1. If we specify some targets explicitly and have browserslist field in package.json it will merge targets.
2. If we haven't any targets and set browserslist field in package.json it will use targets from browserslist field.
3. If we have browsers option in targets and browserslist field in pckg.json it will use just browsers option in targets.

I really want to see more ideas to get configuration as simple as possible and not contradict browserslist config.
This approach could cause some problems if you want to use babel for node apps and just keep browserslist config for other things.
But it could be resolved by setting browsers: []. Maybe we need to add false value to prevent browserslist config searching.
Or suggested by @ai approach by explicitly specifying browserslist: true to allow config search.

[ai]

I think browsers: [] will be good for node-only projects. Also if developers could put browserslist config to styles/ subdirectory and it will not affect on babel-preset-env.

[exarus]

@yavorsky Thank you for explanation.
So now if I want to use package.json browserslist field, I should specify browsers: [].
I think that it may be better to specify a bit more explicit in one of these ways:

• browsers: "browserslist"
• browserslist: true, as suggested by @ai
• browsers: true. May make reader thinking in such way:

Ah, the browsers are the target of babel. So there might be a browsers list somewhere around

As for me, the empty array is associated with no target browsers by a reader of .babelrc. Not with some other config-based approach.

[ai]

In Autoprefixer if you specify browsers: [], it will specify no browsers at all. Autoprefixer will not look into browserslist after it.

[yavorsky]

We've added 2.0 milestone, so it will be published with babel-preset-env 2.0 and we have some time to decide what API would be the best. Thanks for helping with it 😊

[PDCS]

C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\DotNet\Microsoft.DotNet.Publishing.targets(149,5): Error : [Browserslist] Could not parse E:\Visual Studio 2015 #

I have the above Error in which I am unable to publish to azruewebsites.net the local build and test are okay.

C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\DotNet\Microsoft.DotNet.Publishing.targets(149,5): Error : [Browserslist] Could not parse E:\Visual Studio 2015\Projects\ParadiseClumberSpaniel\package.json. Ignoring it.

Anyone have an idea on what is wrong?

[jimblue]

Hi !

Any news about this?
I made a lot of tests but I can't make the magic happen...

Thanks 😄

[ghost]

Any follow up for this?

[marcofugaro]

Yeah it would be great with browserslist: true

[damianobarbati]

Any news on this?

[swernerx]

Very unfortunate that this actually trivial change is not being implemented.

I am currently using a workaround in our centralized Babel preset builder which uses the fact that browserslist itself offers the lookup behavior when passing undefined or null. See: https://github.com/ai/browserslist/blob/148ca522e20775046f7f10a6973749af4964604b/index.js#L168

What I do is actually importing 'browserslist' on my own and executing it with a first parameter of null. Then I pass that result array to babel-preset-env. Quick and dirty but seems to work. Code: https://github.com/sebastian-software/edgebabel/blob/4e42964c411569f225ae6454aaea448a67a9aaa4/src/index.js#L53

I would vote for browsers: true BTW. null looks too falsy and an empty array feels wrong as well...

[vladimirvolek]

Any news on this?

[marvinpinto]

If I'm not mistaken, this has already been implemented in #161 and it's available in the 2.x-beta.

[damianobarbati]

@swernerx @vladimirvolek babel-preset-env@2+ already supports all of this.
I've been using it for weeks by now, example here https://github.com/damianobarbati/react-app/blob/master/package.json

[existentialism]

Yep, closing this.