4 ms·

You can usually browse npm for what you need, and when you want to use it, look at unpkg.com/<name of package> Usually this will give you a .min.js file ready

You can usually browse npm for what you need, and when you want to use it, look at unpkg.com/<name of package> Usually this will give you a .min.js file ready for you to script include on your site, for example, unpkg.com/mithril Sometimes library authors don't default the export to a browser ready minified version or ESM module, in which case, you can snoop around the built package at unpkg.com/browse/mithril/. Most READMEs worth a damn should tell you how to use their libraries without npm if possible. Unfortunately, a lot of library authors suck.

joshstrange 3y ago
> Unfortunately, a lot of library authors suck. The nerve of them not catering to the small percentage of use cases for a project they often do in their free time and often for free. The entitlement is real.
- toastercat 3y ago
  Sorry I forgot we're not allowed to criticize open-source maintainers ever. But as a library author myself, it takes less than 10 seconds to add such a section in my README.
lakpan 3y ago
Unpkg just serves the raw files, which may contain require() calls or import from other npm packages. That won’t work. The closest service is https://esm.sh https://esm.sh, but you can’t download from it.
- toastercat 3y ago
  Unpkg serves whatever is published to NPM, and if it's a library intended for the browser, that often includes minified versions ready for use in script tags, for example, https://unpkg.com/mithril@2.2.2/mithril.min.js https://unpkg.com/mithril@2.2.2/mithril.min.js. Sometimes the default export is CJS (which has require() calls), in which case, you can usually use the browse url that I mentioned to see if there's another export you can use. https://esm.sh/ https://esm.sh/ is definitely a good option too if you're OK with modules.
  - lakpan 3y ago
    Yeah but that's rarely the case, you can't offer that as a generic "solution" to the problem at hand. It's just Mithril's choice to both publish to npm and to officially link to unpkg. Packages can make different choices, like publishing to GitHub releases or just to include the file in the GitHub repo. The reality is that only frameworks and very popular browser-specific packages do that.
    - toastercat 3y ago
      I said "often", but you say "rarely", so I guess we'll just have to agree to disagree here. :)

joshstrange 3y ago

> Unfortunately, a lot of library authors suck. The nerve of them not catering to the small percentage of use cases for a project they often do in their free time and often for free. The entitlement is real.

toastercat 3y ago
Sorry I forgot we're not allowed to criticize open-source maintainers ever. But as a library author myself, it takes less than 10 seconds to add such a section in my README.

lakpan 3y ago

Unpkg just serves the raw files, which may contain require() calls or import from other npm packages. That won’t work. The closest service is https://esm.sh https://esm.sh, but you can’t download from it.

toastercat 3y ago
Unpkg serves whatever is published to NPM, and if it's a library intended for the browser, that often includes minified versions ready for use in script tags, for example, https://unpkg.com/mithril@2.2.2/mithril.min.js https://unpkg.com/mithril@2.2.2/mithril.min.js. Sometimes the default export is CJS (which has require() calls), in which case, you can usually use the browse url that I mentioned to see if there's another export you can use. https://esm.sh/ https://esm.sh/ is definitely a good option too if you're OK with modules.
- lakpan 3y ago
  Yeah but that's rarely the case, you can't offer that as a generic "solution" to the problem at hand. It's just Mithril's choice to both publish to npm and to officially link to unpkg. Packages can make different choices, like publishing to GitHub releases or just to include the file in the GitHub repo. The reality is that only frameworks and very popular browser-specific packages do that.
  - toastercat 3y ago
    I said "often", but you say "rarely", so I guess we'll just have to agree to disagree here. :)