Discussion: First-class integration with npm

[FredKSchott]

I want to make anyone following this repo aware of a discussion going on over in npm-land. Someone from the npm team reached out to me a few weeks back asking how I would feel if npm CLI integrated @pika/pack into a future version of npm, basically to replace their pack and publish commands. I expressed interest in the idea, and today this RFC was shared.

npm RFC: @pika/pack available in stock npm
RFC Issue: npm/rfcs#35
Tweet: https://twitter.com/ReBeccaOrg/status/1103107880448712704
My Initial Thoughts: npm/rfcs#35 (comment)

Feel free to ask any questions here, or in the official RFC thread. Again, no action needed, just wanted to make anyone watching this repo aware of the discussion and give a chance to ask/answer questions here if they'd rather.

[matthewp]

This is really great. From reading that thread it sounds like their focus is more on the pipeline part of things. Another important aspect of pika/pack is setting all of the CommonJS fields. To your understanding would they being doing that as well?

Would they support web_modules?

[FredKSchott]

Yea i think that’s right. Especially because np has existed forever as a better publish, I think what they’re most excited about is:

• the pipeline concept
• the idea of “packing” to a separate pkg/ dir

Yea, I’m hoping that they’ve actually played with it enough to know what it’s opinionated about (project layout, entrypoint file location, setting the property.json fields for you, etc.). I’m guessing that the rfc convo/thread will flesh those out naturally.

I’d actually be super curious to know what they think about https://github.com/pikapkg/web, it’s not too far off from the “npm asset” work that they were doing a few years ago but then abandoned. I may follow up offline with Kat to ask.

[zkat]

npm asset was a proof of concept that we did as part of our general effort to support ESM, and at the time, it was just a little experiment to show what could be done if Node had ESM built-in. We ended up dropping it mostly because everything else took priority over it.

@pika/web very much seems like the sort of thing npm asset should have matured into, although I believe it lacks certain important bits for something like that, such as, well... assets themselves (separate html/css files, images, etc. I believe @pika/web prefers to pack everything into a single file?).

Anyway, this is to say, I'm very excited about @pika/web, too, and it's definitely the sort of thing we should integrate as well. :)

[tunnckoCore]

@FredKSchott: the idea of “packing” to a separate pkg/ dir

If they are considering this, then we should first make "the standard" better (name and structure) than this dist-*, I always wonder why you just don't make it dist/web, dist/node (in my opinion it should even be dist/cjs, dist/esm instead). As regarding the "separate pkg dir", npm has always had the option to define a dir from which to publish (the default is . cwd).

I'm jumping now on the rfc thread.

edit: Or even better, follow the names of the fields, dist/module, dist/main, dist/esnext, dist/unpkg, dist/umd - a tons better and intuitive and clean. :)

[FredKSchott]

Having each dist be top level in the pkg/ means that relative imports out of the directory don't need to change. For example, importing ../assets/X works from both the src/ directory & dist-web/ directory when assets are included in the package. That was the main reason behind this design decision.

[pika-ci]

🚚 This issue has been moved!
Continue the discussion on our project message board:
https://www.pika.dev/packages/@pika/pack/discuss/1099 • What is this?