use @pika/pack to build ESM, UMD

[FredKSchott]

@pika/pack: package.json config

  "@pika/pack": {
    "pipeline": [
      ["@pika/plugin-standard-pkg"],
      ["@pika/plugin-build-web"],
      ["@pika/plugin-build-umd", {"name": "customAttributes"}]
    ]
  },

Build Summary

Summary of Changes

• Uses @pika/pack to build UMD, ESM distributions automatically
• ✨Removed attr.js: Now handled by @pika/pack!
• ✨Removed global.js: Now handled by @pika/pack!
• Moved remaining index.js & registry.js into src/ directory
• Updated tests & README
• ESM -> UMD: preserving the current UMD interface wasn't possible. Since the entire module is exported as window.customAttributes, the default registry has to live as a property of that namespace ( at customAttributes.default or something similar).
• Recommend moving examples & tests to use the more intuitive ESM interface: import customAttributes from 'custom-attributes'

[matthewp]

Wow thanks a lot! I'm on vacation this weekend so I'll have to look into it next week. I'll likely tweak some stuff, but a lot of thanks for getting it started.

[FredKSchott]

@matthewp I would love to include a link to custom-attributes in a "packages already using @pika/pack" section of the announcement post. If you have any interest lmk!

[matthewp]

Yeah, that would be great! Reviewing this now..

[matthewp]

Hm, yeah I don't want to have to do this... Will look for a way around.

[FredKSchott]

Yea, curious if you have any thoughts. Moving to ESM in your examples would definitely move people in that direction, but I didn’t see anything in rollup that lets you define your UMD module as an actual function

[matthewp]

I'm going to go ahead and merge and then cleanup the .default problem after.

[matthewp]

@FredKSchott is it possibly to specify a different output file for the web build? I would like to not make users go deep with https://unpkg.com/custom-attributes/pkg/dist-web/index.js but rather something shorter like https://unpkg.com/custom-attributes/index.js.

[FredKSchott]

Since you publish the pkg directory directly, technically it will just be https://unpkg.com/custom-attributes/dist-web/index.js , but I do get your point about length.

Would it be enough to let you add the “unpkg” entrypoint so that you can just do https://unpkg.com/custom-attributes ?

[matthewp]

Wouldn't that result in redirects though?

I guess I'd be ok with dist-web/ if the src/ folder was available directly in /. I really want my packages to be web-first, not web as a compile target. dist-web/ is fine as a bundle for smaller download sizes.

Is there a way to get pika/pack to copy the source files over into the pkg/ folder?

[matthewp]

For clarity what I'd really like is:

pkg/
- dist-web/
- dist-umd/
- index.js
- registry.js

Does adding index.js and registry.js to "files" make this happen?

[FredKSchott]

Hmm, okay let me think about that a bit. The dist-* structure does serve a technical purpose: when there are shared assets/ like CSS or JSON or WASM, all ../assets relative imports/paths out of the src/ directory will still work no matter what the dist-* name actually is, allowing for shared assets among multiple distributions.

Essentially what you're requesting is cosmetic (/custom-attributes/dist-web/index.js vs. /custom-attributes/index.js) and a little niche, but definitely still valid. I could see a plugin that moves a selected already-built dist down a level into the root pkg/ (in your case, dist-src) at the end of the build, maybe with a warning/failure if an assets/ directory is detected to warn about broken relative imports.

fwiw, since your package only contains dist-web & dist-umd, I would still definitely consider it "web-first", since both module formats work on the web.

[trusktr]

Looks like the README is outdated:

<script src="node_modules/custom-attributes/attr.js" defer></script>

Maybe that should be

<script src="node_modules/custom-attributes/dist-umd/index.js" defer></script>

?

[trusktr]

What about calling dist-web dist-es or dist-esm?

[FredKSchott]

That's not a bad idea. We'll probably need to make a change in Pika anyway once Node gets ESM support, or decide that dist-node & dist-web can still be different even if both are ESM.

[trusktr]

Are these dist-* folders only referring to the type of the module output?

If so, then I think what makes sense to me, as far as module formats is something like dist-cjs, dist-es, dist-umd, dist-amd, etc. I think people will know cjs is commonjs for node.

[trusktr]

Turns out this is a breaking change. In previous code of mine I was able to do the following to register the global customAttributes registry:

import 'custom-attributes/attr.js'

So I could build my app with a bundler like Webpack or Meteor, and it would cause the global to be defined, so I could use it like a polyfill.

But now I'm installing from git (I have a fork of custom-attributes), and I'm importing it like this:

import 'custom-attributes/pkg/dist-umd'

I've committed the pkg folder to the repo, so that it is available.

But due to the environment that I'm in (Meteor 1.6, which uses CommonJS as the underlying module system that ES modules compile down to), the UMD module sees the exports object and does not therefore assign to global. My code then tries to use the undefined variable.

[FredKSchott]

Can you import 'custom-attributes/pkg' instead? I would hope that all the tools would be able to handle that correctly, based on whether they wanted UMD, ESM, etc.

[trusktr]

Looks like Meteor reads the main field.

[trusktr]

Browserify uses the require.resolve algorithm, which uses the main field.

[trusktr]

I'm guessing that @pika/plugin-build-node would be the one to includes the main field in the output?

If so, perhaps plugin-build-node should also be included in case people are consuming things with certain tools (f.e. Meteor, Browserify, or even plain Node.js with a DOM environment). Some testing environments use CommonJS format, with jsdom or similar for mocking the DOM (f.e. Jest does this). May as well include the node/cjs build with a main field, for those cases.

EDIT: Heck, who knows, maybe someone is still using RequireJS in a project. Might as well include plugin-build-amd just in case.