
Pika/pack – NPM packaging, reimagined - pimterry
https://www.pikapkg.com/blog/introducing-pika-pack/
======
skrebbel
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.

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

~~~
TAForObvReasons
YMMV but [http://gs.statcounter.com/browser-market-
share/desktop/world...](http://gs.statcounter.com/browser-market-
share/desktop/worldwide) 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.

~~~
shados
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

------
rubyn00bie
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."

~~~
andrewbarba
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.

------
Osiris
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.

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

~~~
Osiris
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 .

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

npm install some-library -type umd

and have npm server handle this automatically.

