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

sync #1

Merged
merged 48 commits into from
May 31, 2020
Merged

sync #1

merged 48 commits into from
May 31, 2020

Conversation

mljsgto222
Copy link
Owner

No description provided.

ChALkeR and others added 30 commits February 18, 2018 22:37
This avoids using Buffer constructor API on newer Node.js versions.

To achieve that, Buffer.from presence is checked, with validating that it's
not the same method as Uint8Array.from.

Refs:
https://nodejs.org/api/deprecations.html#deprecations_dep0005_buffer_constructor
1. In allocBuffer(), ensure buffers allocated with new Buffer() are zero-filled.
   On newer Node.js versions, Buffer.alloc() zero-fills already.

2. In newBufferFrom(), throw when 'data' argument is a number.
   On newer Node.js versions, Buffer.from(number)/new Buffer(number, encooding)
   throw already.
* Replace core-js with the much smaller set-immediate-shim.
* Remove es6-promise as it is unused.
* Update lie and readable-stream.

The change from core-js to set-immediate-shim reduces the install size
of jszip from 9.1MB to 2.2MB.  The ponyfil for setImmediate is all that
was used from core-js.
Fix deprecated Buffer constructor usage and add safeguards
As these weren't published properly to npm
the example has a minor type: it uses the `new_zip` var (an instance of JSZip) to call new_zip.file('hello.txt').
The correct way is to call the finction `file` on the obtained zip object.
It depends on Chrome now, which causes issues on build machines
Minor fix in `Read a zip file`
Update browsers used for automated testing
Stuk and others added 18 commits July 3, 2019 14:32
No functional changes, just a change in dependencies
Found via `codespell -q 3` in downstream sweethome3d
When webpack/rollup or another bundler, implementing the
[`browser-resolve`](https://www.npmjs.com/package/browser-resolve)
spec tries to resolve `jszip` for a browser-based project they fail
with:

```
ERROR in ./node_modules/jszip/lib/readable-stream-browser.js
Module not found: Error: Can't resolve 'stream' in '/node_modules/jszip/lib'
```

Since you already produce a browser build, we just need to point to
it inside of `package.json`'s `browser` field.

PS: You'd probably want to double check the semantics of `"."`.

Looking at `browser-resolve` it seems that everything will work
as expected. Also, trying empirically with webpack, everything worked
out, but few more pairs of eyes would be greatly appreciated.

Also @sokra should be able to share a valuable opinion.

Fix #524
Fix #521
Fix #477
Misc. doxy and trivial source comment typo fixes
@mljsgto222 mljsgto222 merged commit 2cb01a3 into mljsgto222:master May 31, 2020
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

Successfully merging this pull request may close these issues.

8 participants