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

Bug: Template literals break older browsers #3630

Closed
jginsburgn opened this issue Jan 25, 2021 · 7 comments · Fixed by karronoli/redpen#10
Closed

Bug: Template literals break older browsers #3630

jginsburgn opened this issue Jan 25, 2021 · 7 comments · Fixed by karronoli/redpen#10
Assignees
Labels

Comments

@jginsburgn
Copy link
Member

jginsburgn commented Jan 25, 2021

Either:

  1. (Better) Include transpilation for older JavaScript compatibility during buildtime of static assets.
  2. (Good, and best if combined with 1) Set up testing with IE.
  3. (Easy) Remove uses of template literals where they have been introduced (see below) and include rules for disallowing them.

Current occurrences of template literals (upon superficial skimming):

  1. titleElement.textContent = `Karma v ${VERSION} - ${connectionText}; test: ${testText}; ${pingText}`
  2. updateConnectionStatus(`reconnecting in ${sec} seconds`)
  3. updatePingStatus(`ping ${latency}ms`)
  4. self.updater.updateTestStatus(`karma_error ${message}`)

@johnjbarton awaiting your feedback on this...

@jginsburgn
Copy link
Member Author

Ditto for arrow functions and their implications (i.e. use of this and others).

@devoto13
Copy link
Collaborator

See #3629 for (3).

@jginsburgn
Copy link
Member Author

@devoto13 what do you think of the other options ((1) and (2))?

@devoto13
Copy link
Collaborator

I think (2) is a must to prevent such regressions in the future.

Re (1) I'm a bit on the fence. On one hand, it would be nice to write modern client JS and let tooling downlevel it to work in all browsers. We also already have a build process for client JS, so extending it with more capabilities wouldn't really change a workflow. On the other hand, it means more build tools to keep track of and maintain. In the past @johnjbarton didn't want to introduce more build tools to the repository, so I will let him decide.

@johnjbarton
Copy link
Contributor

johnjbarton commented Jan 25, 2021

(2) is essential, but I can't get either browserstack or saucelabs to work in the time I had available.
(1) I think we should migrate the source to TypeScript and we could start with client/*. It brings a lot more tooling and issues but the benefits are also much larger and the tool support unequalled.
(3) I sent #3632 for the ugly option.

@devoto13
Copy link
Collaborator

@johnjbarton I can spend some time on debugging the cross-browser testing later this week if you grant access to BrowserStack / SauceLabs to devoto13 at gmail.com. So I can access their web apps and see what happens inside a VM.

karmarunnerbot pushed a commit that referenced this issue Jan 25, 2021
## [6.0.2](v6.0.1...v6.0.2) (2021-01-25)

### Bug Fixes

* avoid ES6+ syntax in client scripts ([#3629](#3629)) ([6629e96](6629e96)), closes [#3630](#3630)
@karmarunnerbot
Copy link
Member

🎉 This issue has been resolved in version 6.0.2 🎉

The release is available on:

Your semantic-release bot 📦🚀

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