UMD Plugin - Possibility to pass config to babel-preset-env

[JonatanSalas]

Is it there a chance that we can pass configuration for babel-preset-env to @pika/plugin-build-web?

In our enterprise, we're building a UI-Component library using pika, our trouble is that currently we're in need to support IE11 and last 3 browser versions, I would like to configure the target so babel-preset-env determines how to transpile the code.

Anyway, thanks!

PD: This tool is pretty awesome!

[FredKSchott]

Thanks @JonatanSalas! Just to make sure I understand, would you like this added to plugin-build-web, or plugin-build-umd? @pika/plugin-build-web is meant to output ESM, so I don't think IE11 support is in scope there.

For the UMD plugin, this makes much more sense. In fact, I wonder if that should just be the default. I had grabbed the current support list from this article:https://jamie.build/last-2-versions

browsers: [
  ">0.25%",
  "not ie 11",
  "not op_mini all"
],

I think it makes sense to remove "not ie 11" from the UMD build, since the goal is to work for consumers/projects which can't support the more modern ESM build.

[JonatanSalas]

Hi @FredKSchott! Thanks for your response!

I was referring to @pika/plugin-build-umd! Sorry!

If you want I can make a PR, I was thinking of doing at first, but at the end, I made the choice to open an issue so we can discuss a little, and see your thoughts on it.

[FredKSchott]

No that makes total sense to me. I went ahead and made this change: a599d60

Does that cover your use case? We can still discuss passing a custom config as well, but if this is enough for you then I'd rather wait until we had a real use case to discuss.

[JonatanSalas]

For now, I think it solves our case. I will upgrade the plugins, test it, and let you know!

Thank you very much for your faster response 😄

[jacobrask]

I think this is needed for build-web as well. Several tools use the ‘module’ field if it exists, the ‘main’ field exports commonjs modules, that should be the only difference between the entries. Your bundle could be configured to support IE 11 or not, but it’s not obvious at all that the module field should be overloaded with this info.

Tools like Next.js will not let you change the mainField you use, which means you can’t use Next to consume modules built with pika and support any browsers without native esmodules.

[JonatanSalas]

Yep! That's totally true @jacobrask.

We also build our apps with Next.js, a workaround to that is to transpile node_modules for production build so you can leverage the browsers you want. That's what we currently do.

[kjkta]

I agree with @jacobrask.

Can I ask @FredKSchott why plugin-ts-standard-pkg forces target/module es2020/esnext instead of just taking using the tsconfig? I'd happy to contribute a solution but I'm not sure if this is against the idea of pika pack / the "standard" plugin. I think es2020 is a great default, but it would be also great to have the option.

https://github.com/pikapkg/builders/blob/master/packages/plugin-ts-standard-pkg/src/index.ts#L125

PS: Also freaking loving the pika ecosystem, so THANKS!

[FredKSchott]

Thank you! 😄

Right now the the workflow exists to build your package into pkg/dist-src/ using the latest JS spec. From there, we can then compile your common, modern "dist-src" directory down to any specific environment targets: Node.js, Browsers, Deno, etc.

This solves the problem where it's hard to know what "target" to choose, when you're publishing a library. Most authors (myself included) end up choosing something more legacy than needed when the decision is up to them, so this tool exists to automate that unknown for you.