This repository has been archived by the owner. It is now read-only.

Question: Supports `browserslist` config on package.json? #149

Closed
amilajack opened this Issue Jan 21, 2017 · 29 comments

Comments

Projects
None yet
@amilajack

amilajack commented Jan 21, 2017

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

@yavorsky

This comment has been minimized.

Show comment
Hide comment
@yavorsky

yavorsky Jan 21, 2017

Member

@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.

Member

yavorsky commented Jan 21, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@amilajack

amilajack Jan 21, 2017

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

demo of plugin usage

amilajack commented Jan 21, 2017

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

demo of plugin usage

@ai

This comment has been minimized.

Show comment
Hide comment
@ai

ai Jan 24, 2017

@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.

ai commented Jan 24, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@yavorsky

yavorsky Jan 24, 2017

Member

@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.

Member

yavorsky commented Jan 24, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@ai

ai Jan 24, 2017

@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?

ai commented Jan 24, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@yavorsky

yavorsky Jan 26, 2017

Member

@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 🙃

Member

yavorsky commented Jan 26, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@existentialism

existentialism Jan 26, 2017

Member

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?

Member

existentialism commented Jan 26, 2017

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

This comment has been minimized.

Show comment
Hide comment
@ai

ai Jan 26, 2017

@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 commented Jan 26, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@ai

ai Jan 26, 2017

@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?

ai commented Jan 26, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@yavorsky

yavorsky Jan 26, 2017

Member

@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.

Member

yavorsky commented Jan 26, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@ai

ai Jan 26, 2017

@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.

ai commented Jan 26, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@amilajack

amilajack Jan 27, 2017

Off topic: I'm Sri Lankan! 😂

amilajack commented Jan 27, 2017

Off topic: I'm Sri Lankan! 😂

@exarus

This comment has been minimized.

Show comment
Hide comment
@exarus

exarus Mar 3, 2017

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

exarus commented Mar 3, 2017

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

@ai

This comment has been minimized.

Show comment
Hide comment
@ai

ai Mar 5, 2017

@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?

ai commented Mar 5, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@yavorsky

yavorsky Mar 6, 2017

Member

@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.

Member

yavorsky commented Mar 6, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@ai

ai Mar 6, 2017

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.

ai commented Mar 6, 2017

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

This comment has been minimized.

Show comment
Hide comment
@exarus

exarus Mar 8, 2017

@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.

exarus commented Mar 8, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@ai

ai Mar 8, 2017

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

ai commented Mar 8, 2017

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

@yavorsky

This comment has been minimized.

Show comment
Hide comment
@yavorsky

yavorsky Mar 8, 2017

Member

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 😊

Member

yavorsky commented Mar 8, 2017

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

This comment has been minimized.

Show comment
Hide comment
@PDCS

PDCS Mar 13, 2017

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?

PDCS commented Mar 13, 2017

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

This comment has been minimized.

Show comment
Hide comment
@jimblue

jimblue Apr 3, 2017

Hi !

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

Thanks 😄

jimblue commented Apr 3, 2017

Hi !

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

Thanks 😄

@yavorsky yavorsky added the Has PR label Apr 3, 2017

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Apr 14, 2017

Any follow up for this?

ghost commented Apr 14, 2017

Any follow up for this?

@marcofugaro

This comment has been minimized.

Show comment
Hide comment
@marcofugaro

marcofugaro Apr 19, 2017

Yeah it would be great with browserslist: true

marcofugaro commented Apr 19, 2017

Yeah it would be great with browserslist: true

aduth added a commit to aduth/dones that referenced this issue May 23, 2017

Specify target browsers by package manifest
Will need to reconcile when babel-preset-env detects natively

See: babel/babel-preset-env#149

Upgrades postcss-loader
@damianobarbati

This comment has been minimized.

Show comment
Hide comment
@damianobarbati

damianobarbati Jun 6, 2017

Any news on this?

damianobarbati commented Jun 6, 2017

Any news on this?

@swernerx

This comment has been minimized.

Show comment
Hide comment
@swernerx

swernerx Jun 19, 2017

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...

swernerx commented Jun 19, 2017

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

This comment has been minimized.

Show comment
Hide comment
@vladimirvolek

vladimirvolek Oct 20, 2017

Any news on this?

vladimirvolek commented Oct 20, 2017

Any news on this?

@marvinpinto

This comment has been minimized.

Show comment
Hide comment
@marvinpinto

marvinpinto Oct 20, 2017

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

marvinpinto commented Oct 20, 2017

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

@damianobarbati

This comment has been minimized.

Show comment
Hide comment
@damianobarbati

damianobarbati Oct 20, 2017

@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

damianobarbati commented Oct 20, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@existentialism

existentialism Oct 20, 2017

Member

Yep, closing this.

Member

existentialism commented Oct 20, 2017

Yep, closing this.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.