Create Multiple target build steps: What's the designed behavior, is it supported

[Renoir Boulanger]

Hi @egoist, (Thanks for your work!),

I'm looking at setting up bili to transpile with babel modules when we want the transpiled code to have a version for both browser, and others (node is one).

I'm unsure if it's because I haven't understood the documentation about this, or I missed something.

Reproduction repo: renoirb/experiments-201907-bili-babel-preset-env-multiple-target-builds

I'm aware bili piggy back on @babel/preset-env. That we can pass an object with "targets" (e.g. {node: 10}). But I'm unsure what it does when I do {node: 10, browsers: ['last 2 versions']} AND use bili --target node.

When I look at log messages and debug, I see that it treats everything as a browser target. Is that normal?

• What's the default behavior?
• What is the plan, or intended setup (or the "as designed" way of doing it)?

Thank you

[Renoir Boulanger]

OK, the reproduction repo should work for illustrating my question regarding a way to properly do for my question.

It felt a lot like flipping switches and breaking things that were previously OK.
But now tests, and building aren't throwing errors.

So the repo builds code, and I use target argument between variabts.

Am I doing something redundant here?

[Renoir Boulanger]

OK. After another day, I see better what's at play.

First, let me reword my original requirement.

1. One code base
2. Build steps where we can leverage --target bili argument to tell if it's for node, or browser
3. Pick only relevant items from Browserslist (?)

What I understand is that we delegate things to Rollup, Babel (including babel/preset-env), rollup-plugin-typescript2, etc. That the "bili/babel" preset does the handling of babel/preset-env.

Also, babel/preset-env can load .browserslistrc

So we have either to:

• Using BROWSERSLIST shell environment for each build target Set BROWSERSLIST="node >= 10" then run bili
• In some way (hooks, how?) change output.targets
• Leverage babel/preset-env to filter out only relevant maybe hook in some way into bili/babel preset.

But which way would be simplest?

I see a few ways, but I'm unsure which is "as designed" (or with lowest friction):

1. Have a .browserslistrc with all targets, including node. Or not. I'm unsure which is best. Then make a rollup-plugin-babel Custom Plugin Builder ... and find way to take ConfigOutput target property in bili.config.js inside a extendConfig() method and do things about switching
2. No .browserslistrc, flip in some way bili.config.js inside a extendConfig() method, do something (?), maybe override process.env.BROWSERSLIST = '<coma separated list of browserslist, without node targets>' like @babel/preset-env says about BrowsersList integration, which would make sense since by default babel/preset-env will by default take node current if non exists
3. ?