swc-project / swc

Rust-based platform for the Web
https://swc.rs
Apache License 2.0
31.18k stars 1.23k forks source link

Browserslist not being applied from .browserslistrc or package.json #3365

Open tomdracz opened 2 years ago

tomdracz commented 2 years ago

Describe the bug

Documentation at https://swc.rs/docs/configuration/supported-browsers#browserslist suggests that if targets property is omitted in .swcrc, the browserslist should be read from .browserslistrc or package.json browserslist key.

This does not seem to be the case, only way to seemingly enable different targets is to specify the "targets" key in ".swcrc".

Example file at test.ts:

const myTest = 'foobar'

const someFunc = (test: string) => {
  console.log(test)
}

const myBar = someFunc(myTest);

and .browserslistrc:

chrome 95

Input code

yarn run swc ./test.ts -o ./test.js

Config

{
  "jsc": {
    "parser": {
      "syntax": "typescript",
      "tsx": true
    }
  },
  "env": {
    "debug": true,
  }
}

Playground link

No response

Expected behavior

Browser targets from .browserslist file applied. Debug output should match the one when "targets" is specified in .swcrc.

Debug output with "targets": "chrome 95" in .swcrc:

Targets: BrowserData { chrome: Some(Version { major: 95, minor: 0, patch: 0 }), and_chr: None, and_ff: None, op_mob: None, ie: None, edge: None, firefox: None, safari: None, node: None, ios: None, samsung: None, opera: None, android: None, electron: None, phantom: None, opera_mobile: None, rhino: None }

Actual behavior

Targets from browserslist not being applied. A defaults (?) applied instead as per debug output:

Targets: BrowserData { chrome: Some(Version { major: 94, minor: 0, patch: 0 }), and_chr: None, and_ff: None, op_mob: None, ie: Some(Version { major: 11, minor: 0, patch: 0 }), edge: Some(Version { major: 95, minor: 0, patch: 0 }), firefox: Some(Version { major: 78, minor: 0, patch: 0 }), safari: Some(Version { major: 13, minor: 1, patch: 0 }), node: None, ios: Some(Version { major: 12, minor: 2, patch: 0 }), samsung: Some(Version { major: 14, minor: 0, patch: 0 }), opera: Some(Version { major: 80, minor: 0, patch: 0 }), android: Some(Version { major: 95, minor: 0, patch: 0 }), electron: None, phantom: None, opera_mobile: None, rhino: None }

Version

@swc/cli: 0.1.55 @swc/core: 1.2.133

Additional context

No response

RiESAEX commented 2 years ago

related to #3085

Inori-Lover commented 2 years ago

@RiESAEX any update? relate issue had closed but i still face this issue

jer-sen commented 2 years ago

@RiESAEX same issue here, lost a lot of time on this. I had to copy/past my .browserslist content in my .swcrc file.

peterhirn commented 1 year ago

Simply copy/pasting the .browserslist content into .swcrc isn't good enough. Browserslist and this project are out of sync, eg. not dead still includes ie 11 here, but was removed from Browserslist a while ago https://github.com/browserslist/browserslist/pull/701.

scssyworks commented 1 year ago

Do we have any update on this issue because it seems to have not fixed yet. Still facing this issue with the latest version.

scssyworks commented 1 year ago

I am using swc core version 1.3.70 and I am still facing the issue that browserslistrc file is not read if we omit the env.target options. I am not sure why moderators felt that my previous comment was a spam. I am just interested to know if some work has been done for this issue. It's my humble request to moderators to rather close this ticket if you don't want any further threads. Simply marking the comment as a spam is serious and does not reflect good will. My comment did not contain any bad messages.

kwonoj commented 1 year ago

@scssyworks is there any updates.. is one of the kinds of message that potentially burdens project maintainer. Even though question is being asked without any intention to harm, it creates unnecessary notification burden to maintainer without meaningful information: Issue stay as opened, and core team / maintainer did not update it means there is no update. For this specific repo, we mark it either as off-topic or spam as comment doesn't relates to any information to the issue itself.

I suggest to peek https://github.com/bradfitz/issue-tracker-behaviors#any-update . For your perpective it's simple one request to ask an update, but as project maintainer we daily gets several, or sometimes more than ten or hundreds redundant messages by each individual asks similar way.

kdy1 commented 1 year ago

@scssyworks https://kdy1.dev/posts/2023/1/plus-1-is-spam

dburles commented 1 year ago

While comments like that can be spammy to maintainers, it's not the fault of those leaving them!

The intent of those comments is to highlight that the issue should be treated with a higher priority. I've seen plenty issues with loads of +1 comments. GitHub probably just needs some means of highlighting issues to maintainers that users feel are important.