Pika/pack – NPM packaging, reimagined | Hacker News Reader

Pika/pack – NPM packaging, reimagined

pikapkg.com

70 pointspimterry21 comments

First, I really like the idea behind this. All the babel rollup typescript stuff is a big mess when trying to publish a package.

That said, I feel like the authors made some choices that make their lives easier at the cost of having shipped a virtually useless tool. For example:

    - The standard typescript builder can only generate ES2018
    - The web bundler can only generate ES modules

These two together means that your package won't work on anywhere but the most modern browsers and Node versions, except if your package's users somehow configure their Webpack (or whatever) to run your module through Babel (totally beating the purpose of all this). This is exactly the kind of complication I'd want tools like these to solve for me.

Sure, there's a place for the "this will only work on cutting edge environments", but i'm not sure a tool intended for publishing reusable libraries is that place.

Additionally, a core feature I miss is the ability to have different entry-points for different environments (eg one for node and one for browsers). My library uses the DOM for some heavy lifting and imports JSDOM on Node for that - I'd not want to ship JSDOM to the browser and bloat the download for no reason.

Hope all this improves, I could see myself using this.

To be honest, ditching IE support is hardly "cutting edge".

YMMV but http://gs.statcounter.com/browser-market-share/desktop/world... points to IE at 5.74%, FF at 9.5%, Chrome at 70.88% in January 2019. Of course, you should look at your own user logs to determine usage statistics, but many government sites still recommend using IE.

Also internationally, some countries have disproportionate IE usage and dropping it basically drops that market. In some market segments, IE users also spend more $$$ per user because of corporate customers. It can be really expensive to give up. If your market is young affluent westerners with MacBook pros it might be easier

Maybe in another five years my company can dump IE, but for now we still have about 1% of paying users chugging along on IE 11, and getting them to update soon is a long stretch given that most of this industry still runs on fax machines.

Great, when this tool hits the mainstream in five years it'll be right on time. ;-)

Depends on your audience. If you are B2B, dropping IE means dropping a financially significant chunk of the market. Heck, we were still getting traffic from people using IE9 in the last year, though it was small enough we were able to convince the whole team that it was time to drop support for everything below IE11. Sorry, poor IE9 user :(

This is for libraries.

For you use case you just have to make JSDOM an external package (assuming you use webpack or rollup) and declare it as a peer dependency of your package

That means you still have to add a layer of build configuration on top of this tool, though, which obviates the point of using it at all.

Check out the build-umd plugin, which should give you exactly that (in addition to esm & node builds)

https://www.npmjs.com/package/@pika/plugin-build-umd

That specifically excludes IE 11, which makes it pointless to bother with.

My old workplace (left 4 months ago) is on the verge of dropping IE11 altogether, and as of my leaving, already was only supporting it as a "won't be totally messed up". That's a medium-to-large sized web agency for our sector. IE11 and lower represent sub ~3% of all traffic according to caniuse, people are slowly dropping it.

Only field where I can see this being totally irrelevant is stuff like public sector/uptight corporate intranet with computer still on W7 without any other browser installed than IE9, or very high traffic/wide public stuff. Otherwise IE is starting to fall out of style faster and faster these days.

So far parcel-bundler has been relatively no-hassle for me with Typescript. For multiple entry points you can just do stuff like

   "build": "npm-run-all build",
   "build:node": "parcel build -t node -d dist-node src/node-entry.ts",
   "build:web": "parcel build -d dist-web src/web-entry.ts",

...which is a little extra boilerplate, but not too bad.

From what I learned from digging into Pika/Pack a bit, I think you misrepresented it a bit.

> - The standard typescript builder can only generate ES2018

That's true, but only because the compilation to previous ES versions is meant to be handled by other plugins. For instance, the "web" plugin [1] uses babel-preset-env, which in turn will take your package.json's "browserslist" [2] into account.

> - The web bundler can only generate ES modules

The Pika project seems to be all about promoting ES modules, so it's no wonder that put this option to the forefront. However, there is also an UMD plugin [3] and a "node" (presumably Common.js) one [4].

[1]: https://github.com/pikapkg/builders/tree/master/packages/plu... [2]: https://github.com/browserslist/browserslist [3]: https://github.com/pikapkg/builders/tree/master/packages/plu... [4]: https://github.com/pikapkg/builders/tree/master/packages/plu...

Soo... I thought this was a competitor to Yarn or NPM itself from the title... It's not. It's for publishing NPM packages. It'd be nice if the title of this was what they have on their site as it more accurately describes what this is: "npm package building, reimagined."

Strange, the title felt pretty accurate to me. I had a good sense of what I was about to read (basically guessed it would handle TypeScript from the title), and then was impressed with the additional features.

I've always thought that we should publish our sources to NPM, then during the `npm install` phase, the sources would be compiled (if needed) to your project's settings.

Then you'd have to have your compiler (like typescript or babel) be dependencies instead of devDependencies.

That's not exactly what I meant. I was thinking something along the lines of a more universal way for npm to serve up compatible code without the package publisher having to pre-compile everything to make it compatible with every possible usage scenario. I'm not exactly sure how that would work, but I think it's a bad idea to push all that to package publishers .

That's a cool idea, assuming you mean something like:

npm install some-library -type umd

and have npm server handle this automatically.

Reply on news.ycombinator.com