rfc: @pika/pack available in stock npm

[iarna]

Here's a lil RFC suggesting that maybe @pika/pack should be directly integrated into npm.

rendered

[logicalphase]

That would be a winner. Optimizing at this level could reduce time and resources from download to application build. Very cool proposal.

[aorinevo]

This is related to an open idea on npm.community: https://npm.community/t/auto-publish-mini-version-for-npm-packages/274

Love the RFC!

[FredKSchott]

(Note: I build and maintain www.pikapkg.com & https://github.com/pikapkg/pack)

+1, I'd obviously be thrilled to see npm integrate @pika/pack's approach to package building via simple config and a pipeline of composable build plugins & tools. A few thoughts from reading the RFC:

• We scoped our config to the "@pika/pack" package.json to play well with others, but if a top-level "pipeline" package.json property was blessed by npm we'd love to use it.
• Our standard set of build plugins make some opinionated choices for the benefit of our users & simplicity of the tool, but that may not be right for everyone. For example, our standard set of build plugins assume a single src/index.js entrypoint and bundle the different distributions (web, umd, etc) into single file builds (while still allowing bundlers to tree-shake out unused code in production). Would npm be willing to adopt these opinionated choices? if not, a new set of build plugins would be needed, what would they look like and how would they work?
• We're still pre-v1 both literally and in terms of maturity. While the config interface is straightforward and fairly baked (it borrows heavily from .babelrc), the plugin author experience still needs some time in the oven. This would probably require less time than npm's release schedule, but it's worth mentioning.
• Documentation & Testing are not at all where they would need to be for the type of usage this would entail. It's a one-person show right now, some dedicated time from the npm team (and help from the npm community!) in these two areas would be more-or-less required for this RFC to go well.

[aorinevo]

Just echoing some of my thoughts from the npm.community idea. I think there is value in publishing the build types under a separate scope that mirrors npm. For example, suppose we package redux as umd and cjs, then after building the two build types, publish just the build files along with a slimmed down package.json to @npm-umd and @npm-cjs.

What are your thoughts on this?

[FredKSchott]

I like the idea. Happy to discuss more in a different thread or offline (Edit: hope that doesn't come off as rude, just don't want to crowd out the convo here and make this thread about npm all about me)

[drwpow]

I’m a big fan of @pika/web. I’ve been wanting this bundler to exist for a long time now (even attempted to build it myself before I knew @pika/web was in the works).

The biggest barrier that I ran into also seems to be affecting @pika/web: not enough npm modules ship ESM. When trying to use it, you see this error frequently:

✖ dependency "react" has no ES "module" entrypoint.

With both Rollup (and @pika/pack), it’s now trivial to ship ESM alongside the usual CJS (--format esm, etc.), but that doesn’t mean that every package will just change overnight.

I’d advocate surfacing a warning on npm publish to the author when publishing a package without ESM.

Once enough packages have ESM support, I believe @pika/web will be the new webpack, and will become the defacto way to ship client-side JS (and if not @pika/web itself, it’ll be an identical approach, because browsers now support ESM and this is the first bundler that takes full advantage of that).

[ljharb]

Until node has native ESM support, i don’t think that’s wise advice. Whatever node ships will be the only thing we’ll want the majority of the ecosystem also shipping, and anything different will be immediately obsolete.

[logicalphase]

The original inquiry was from npm, so I have to assume the RFC and ensuing discussions is something they're interested in pursuing. I think the faster we can get to shipping a ready to dev using the browser the better.