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

Question regarding Q&A #265

Closed
belgattitude opened this issue Jul 1, 2020 · 5 comments
Closed

Question regarding Q&A #265

belgattitude opened this issue Jul 1, 2020 · 5 comments

Comments

@belgattitude
Copy link

belgattitude commented Jul 1, 2020

@sindresorhus as ky became a crtical part in our project, would you be open if we provide few P/R's about

    1. [Q&A] Add a ci/cd workflow based on github actions (rather than travis)
    1. [EsCheck] Add a optional step npx es-check es6 ./umd.js to ensure code is valid es6. (we actually transpile ky but if it does not hurt bundle size, why not ?, there's only few code changes to be expected)
    1. [Build] Experiment rollup - babel with a browserlist config (I know that you're supporting modern browsers). We can plug this into rollup or use microbundle/tsdx as well and provide multiple exports (modern...).

Other nice to have (size-limit checks, typescript rewrite...)

What's your opinion on this ?

`

@sholladay
Copy link
Collaborator

Add a ci/cd workflow based on github actions (rather than travis)

Why? Personally, I like Travis. The config is simpler, among other reasons.

npx es-check es6 ./umd.js to ensure code is valid es6

I don't think this is quite what we want. The intention with the UMD build is simply to change the module format, not the target ES version. Which is to say, umd.js is not ES6. It's meant to work in "the latest version of Chrome, Firefox, and Safari" and Node.js, as per the documentation. In practical terms, that basically means you should treat it as ES Next, regardless of what ES features we currently happen to use (e.g. we could start using the nullish coalescing operator). What I think we should do, though, is add a umd.es5.js file, aka #255. That way, you can easily use Ky in older browsers. So we'll have ES Next and ES5.

[Build] Experiment rollup - babel with a browserlist config (I know that you're supporting modern browsers). We can plug this into rollup or use microbundle/tsdx as well and provide multiple exports (modern...).

I'm not necessarily against this, but IMO it wouldn't change much for the codebase, yet it would introduce complex tooling. It's pretty easy to just check the compatibility table on MDN / caniuse.com and only use features that already have broad support. There hasn't been anything I can think of where we've really needed Babel. A few years ago, this would have made a lot of sense. But these days, the spec moves incrementally and the browser vendors are doing a reasonable job keeping up.

@sindresorhus
Copy link
Owner

  1. I like the potential of GitHub Actions, but right now it's too immature (I've tried it on some other projects) and the config it requires is way too verbose and with no way to reuse and share. Travis works fine for now. I'll move to GitHub Actions eventually, but it will probably be a couple of years.
  2. What Seth said.
  3. I appreciate the suggestions, but I try hard to keep the tooling to a minimum. I've been in Node/browser dev for a long time and I've seen how much overhead too much tooling causes.

@belgattitude
Copy link
Author

I've seen how much overhead too much tooling causes.

Indeed...

Used tsdx recently with quite good experience... but i would be happy to try out microbundle on ky (and check a bit how ky-universal still integrate). I'll try to create some time for this.

Thanks for your answers

@belgattitude
Copy link
Author

belgattitude commented Jul 3, 2020

It's meant to work in "the latest version of Chrome, Firefox, and Safari" and Node.js, as per the documentation

Yes that's something I circumvent by transpiling ky... no big deal (except that edge 18 issue)

But I'm thinking for contributors it's gonna be hard time to enter the code. With evolution of tooling / ecosystem, I'm so used to not think of that for years. I'm probably not the only one. that something to consider at some point).

Anyway I like very much what you do ! It's brilliant... but I might not be able to use it for most of my projects

@sholladay
Copy link
Collaborator

Anyway I like very much what you do ! It's brilliant... but I might not be able to use it for most of my projects

This would be solved with #255, right? Would you like to make a PR for that?

I'll close this issue for now since I believe ES5 transpiling via Babel / TypeScript is the only thing we want for now and it already has its own issue. Happy to keep discussing here, though.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants