Create Multiple target build steps: What's the designed behavior, is it supported
renoirb opened this issue · 2 comments
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
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?
OK. After another day, I see better what's at play.
First, let me reword my original requirement.
- One code base
- Build steps where we can leverage --target bili argument to tell if it's for node, or browser
- 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):
- 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 takeConfigOutput
target property in bili.config.js inside aextendConfig()
method and do things about switching - No
.browserslistrc
, flip in some way bili.config.js inside aextendConfig()
method, do something (?), maybe overrideprocess.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 - ?