Closed retry-the-user closed 3 years ago
Well, I need to know how you plan to import the package if you want a single file. I'd assume you want it in the global environment, in which case you can just download the file from the CDN. If you're familiar with the command line:
curl -o fflate.js https://cdn.jsdelivr.net/npm/fflate/umd/index.js
Otherwise, just go to that URL (https://cdn.jsdelivr.net/npm/fflate/umd/index.js
) and copy-paste the contents into a JS file. Then include it in a <script src="fflate.js"></script>
. Now there is a variable fflate
in the global environment, and you can call fflate.deflateSync
or fflate.inflateSync
or whatever you need from your JS file.
If you want to use ES Modules, you'll want to download from skypack. Go to https://cdn.skypack.dev/fflate?min
. You'll see something like this:
/*
* Skypack CDN - fflate@0.6.7
* Remove "min" from url for additional help & instructions.
*/
export * from '/-/fflate@v0.6.7-thPAB2KvXgQEkZa8gX2d/dist=es2020,mode=imports,min/optimized/fflate.js';
export {default} from '/-/fflate@v0.6.7-thPAB2KvXgQEkZa8gX2d/dist=es2020,mode=imports,min/optimized/fflate.js';
Go to the URL in this file, in this case https://cdn.skypack.dev/-/fflate@v0.6.7-thPAB2KvXgQEkZa8gX2d/dist=es2020,mode=imports,min/optimized/fflate.js
. Now you can copy-paste or curl
just like for the global build. Now, just import:
import * as fflate from 'fflate.js';
console.log(fflate.deflateSync(
fflate.strToU8('hello world'.repeat(10))
));
I know this isn't particularly convenient, but I want to encourage the use of build tooling if possible because it allows for tree shaking, or at least the use of CDNs because they tend to be faster than self-hosting if you aren't using a bundler. Hope this helps.
Thanks. An overkill response. It would have been enough to just post the URL https://cdn.jsdelivr.net/npm/fflate/umd/index.js . This is a hackneyed way to offer your software for browser use, especially since you don't even post it in any of your docs. Don't impose your philosophies on coders if you want adoption. I got pako integrated into my code in less than 10 minutes with 3 lines, most of which is just converting to an arraybuffer. Third party CDNs are an unnecessary complexity and increased point of failure, not to mention a potential attack vector. I don't want a server I don't control to impact my services. I don't want a backward incompatible change to break anything. That's MY philosophy. You've apparently decided to support node primarily and the browser as an afterthought. That diminishes my trust in your project, which is a shame, because it really does seem like you've written the best javascript-native compression utility.
I'm sorry you had issues with getting fflate
set up. I gave you such a long response because I care about this project, and it can be left for future readers. NPM is currently the most popular browser package management solution, so I encourage you to try using NPM and a bundler like Webpack (or Parcel if you want something quick-and-dirty).
However, I agree that enforcing philosophy on others isn't a good idea. At the same time, IMO downloading from the CDN is self explanatory. It's a strategy that works for nearly every JS library. The CDN instructions were in the docs, and I assumed anyone who wanted to self host would just download from there, since I used to do that before I used build tooling.
On a practical note, I dont want to tie the distributables to my Git versions because I occasionally push a broken commit, and unless the distributables are left out of sync with the source until a version change, there is no way to prevent some users from downloading those broken builds. If you have an alternative I'm happy to take it.
In any case, thanks for making the issue, and let me know if you have any other problems.
Your docs aren't as good as you think they are. Verbosity is not a substitute for clarity. Your code samples require deciphering your over-engineered chain of tool dependencies to figure out even the most basic usages. As it is, I tried to gzip with your software and it failed, delivering 0 byte files to the server. I'm not interested in pursuing this further. Pako just works and works well. Perfect is the enemy of the good applies here.
You're welcome to continue using your existing solution. If I were to guess, the reason fflate
failed is that your code cannot handle a Uint8Array and was designed for ArrayBuffer; you can convert Uint8Array to ArrayBuffer by getting the .buffer
property of the Uint8Array object, or convert ArrayBuffer to Uint8Array with new Uint8Array(arrayBuffer)
.
The fact that fflate
works with Uint8Array only as both input and output is documented in the first code block in the docs, and it's part of the autogenerated documentation as well. If you don't care to fix your code, Pako will work fine for you.
And by the way, I'm not sure why you're using such an attacking tone. You aren't paying for this software, and even if you were it's very rude to insult both me and my work because you're frustrated with it. Please consider the human.
Where's a distributable for the browser that doesn't require some 3rd party crap like skypack or jsdelivr? I want to host it myself. I don't want to compile packages with node/npm tools. Do something like this: https://github.com/Stuk/jszip/tree/master/dist or https://github.com/nodeca/pako/tree/master/dist
But you say your software works better than the others and supports what I really want (zlib not zip), so I'd like to give it a try, but you don't make it easy.