Remove core-js and provide transpiled ES Module output #192
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
`useBuiltIns` injects loads of polyfills that are installed into the environment. core-js polyfills are very thorough, but that sometimes means that it includes things that are actually totally unnecessary. For example, tus-js-client@2 shipped with a Symbol polyfill, even though it doesn't use Symbols anywhere. Transpiled array rest spread syntax uses `Symbol.iterator`, though, so preset-env figures that `Symbol` is in use, and adds the polyfill. This requires core-js to override things like `Object.getOwnPropertyNames` to exclude polyfilled Symbols, etc, and it just spirals out of control until you have 50KB of polyfills just for array spread syntax and Promises :) The only feature that tus-js-client _actually_ appears to require is `Promise`, which we can reasonably expect users to polyfill.
`"module"` and `"main"` are both commonly used by bundlers. To support
the widest range of browsers, they should be transpiled to ES5. It's
possible and not weird to use newer syntax, but best if people opt in
to it, which they can do with a resolve alias. In webpack for example:
```js
resolve: {
alias: {
'tus-js-client': path.join(__dirname, 'node_modules/tus-js-client/lib')
}
}
```
goto-bus-stop
commented
May 11, 2020
Comment on lines
+11
to
+13
| expect(/^tus::fingerprintA::/.test(key1)).toBe(true); | ||
| expect(/^tus::fingerprintA::/.test(key2)).toBe(true); | ||
| expect(/^tus::fingerprintB::/.test(key3)).toBe(true); |
There was a problem hiding this comment.
Instead of adding a polyfill for startsWith, I just used an older way of doing the same thing. This should prob continue to be done for test code, else we might have more polyfills in the tests than we expect users to have, and we could accidentally depend on them in the library code.
There was a problem hiding this comment.
Absolutely agree, you are right! 👍
Acconut
approved these changes
May 11, 2020
|
Thank you very, very much! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This does two things 'restore' size and bundler support to v1.x levels:
Disable
@babel/preset-env"useBuiltIns"useBuiltInsinjects loads of polyfills that are installed into theenvironment. core-js polyfills are very thorough, but that sometimes
means that it includes things that are actually totally unnecessary.
For example, tus-js-client@2 shipped with a Symbol polyfill, even though
it doesn't use Symbols anywhere. But transpiled array rest spread syntax uses
Symbol.iterator, so preset-env figures thatSymbolis in use,and adds the polyfill. This requires core-js to override things like
Object.getOwnPropertyNamesto exclude polyfilled Symbols, etc, and itjust spirals out of control until you have 50KB of polyfills just for
array spread syntax and Promises :)
The only feature that tus-js-client actually appears to require is
Promise, which we can reasonably expect users to polyfill (and is alreadydocumented as a requirement).
Transpile
package.json"module""module"and"main"are both commonly used by bundlers. To supportthe widest range of browsers, they should both be transpiled to ES5.
Now
lib.esmcontains ES5 syntax + ES Modules syntax, so bundlers withES Modules support can use it. For the browserify build scripts, we need
to add
@babel/plugin-transform-modules-commonjsmanually via a commandline parameter.
It's possible and not weird to use newer syntax, but best if people opt
in to it, which they can do with a resolve alias.
In webpack for example: