You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When I use a browser version unknown for SWC in the browserslist selector, instead of adding no transipilation and polyfills (this is the default @babel/preset-env behavior), everything is transpilled and polyfilled. That's a bit unfortunate, as the browserslist-rs tool used under the hood recognizes only browsers released before June 2024. browserslist/browserslist-rs#25. I'm afraid changing how to handle defaults it's beyond my Rust knowledge 😅
It's fair to assume that unrecognised version of a known browser is one of the most recent versions and it's not added to the internal database yet (in SWC it's provided by browserslist-rs if I got it right). If we apply defaults instead, it breaks workflows where browser selectors are updated regularly based on the real application usage. This is exactly my case of a mid-size B2B SaaS app. We keep selectors aligned with what our customers actually use. This approach doesn't work well with SWC, because it transpiles code to some pretty old ECMA Script version. It worked with Babel, as it doesn't apply any transpilation or polyfills for unknown versions.
The text was updated successfully, but these errors were encountered:
Describe the bug
When I use a browser version unknown for SWC in the browserslist selector, instead of adding no transipilation and polyfills (this is the default @babel/preset-env behavior), everything is transpilled and polyfilled. That's a bit unfortunate, as the browserslist-rs tool used under the hood recognizes only browsers released before June 2024. browserslist/browserslist-rs#25. I'm afraid changing how to handle defaults it's beyond my Rust knowledge 😅
Input code
Config
Playground link (or link to the minimal reproduction)
https://play.swc.rs/?version=1.9.3&code=H4sIAAAAAAAAA0ssrsxLVkgrzUsuyczPU0jLz9eoVtDT0ysoyi8oVqjVVKjmUlBILE%2FMLFFIzs8rzs9J1cvJT0dVY81Vy8UF0qlpDQAfwt5ETwAAAA%3D%3D&config=H4sIAAAAAAAAA3VRQYrDMAy89xVG5x627K2HQukD9gFLWYyttC6yHSwnNJT8vYpJ3aSwPlkzo7E0fmyUAu%2BCawbYq0YT43aCMPRSP%2BQqRdbpgpkF%2BIXTNUWP6qB2319wFn4s%2Bhubt75NyJh6PBKdovcYSm9OXfGeBDqJoDYIwkPI%2Bi4IoPGaTXJthu2LvfF9NijIONvUuauN1%2BFCuNykwE1MXueF8HVAnnLuJ9Dw2SOcec8OLEvDTI3VVxTTrrxyBouN7qj0fVjOgi50jHYVyYK1qO2fiRb%2FE%2BTYEvZIy0hkqlU0FCPXHKZf2oxPuR%2FOf%2BsBAAA%3D
SWC Info output
Expected behavior
No polyfills are added, no transpilation is made.
Actual behavior
Some default transpilation rules apply.
Version
1.9.3
Additional context
It's fair to assume that unrecognised version of a known browser is one of the most recent versions and it's not added to the internal database yet (in SWC it's provided by
browserslist-rs
if I got it right). If we apply defaults instead, it breaks workflows where browser selectors are updated regularly based on the real application usage. This is exactly my case of a mid-size B2B SaaS app. We keep selectors aligned with what our customers actually use. This approach doesn't work well with SWC, because it transpiles code to some pretty old ECMA Script version. It worked with Babel, as it doesn't apply any transpilation or polyfills for unknown versions.The text was updated successfully, but these errors were encountered: