Conversation
|
@lukeed Really appreciate this. Was looking for a dedicated preact babel preset to recommend the other day that works with babel v7 👍 |
|
Me too! I want to slice up what I have on PWA's Repeating config over & over again across build chains is silly |
packages/cli/tests/images/create.js
Outdated
| 'src/tests/header.test.js' | ||
| 'tests/__mocks__/browserMocks.js', | ||
| 'tests/__mocks__/fileMocks.js', | ||
| 'tests/header.test.js' |
There was a problem hiding this comment.
You fixed my PR changes as well 😛
| presets: [[require.resolve('@babel/preset-env'), { | ||
| "targets": { "node": "current" } | ||
| }]] | ||
| }); |
There was a problem hiding this comment.
This will break preact.config.js pretty much everywhere, are we gonna change something about that as well?
There was a problem hiding this comment.
Oh, derp. I've always done module.exports and forgot we allowed that. If it were up to me, we'd drop it entirely.
Will add it back.
| if (Array.isArray(x) && x[0].includes('@babel/preset-env')) { | ||
| x[1].exclude.push('transform-async-to-generator'); | ||
| } | ||
| }); |
There was a problem hiding this comment.
also not sure if this is the best idea, especially if someone wants to extend the config and then async breaks for them
There was a problem hiding this comment.
If they're overwriting, it gets lost anyway. The extend/overwrite happens after this point.. same as before
There was a problem hiding this comment.
but if you extend the config you won't have fast-async because that will override the default one here
There was a problem hiding this comment.
Fast async isn't included in preact preset because it's not a part of getting Preact to run. It's a CLI feature not a preact requirement
There was a problem hiding this comment.
yes, but now if someone makes a custom .babelrc and extends from @preact/babel they'll get errors
There was a problem hiding this comment.
in theory you are changing the behaviour from before though, fast-async was in the extendable config from the cli
There was a problem hiding this comment.
With this package, one can do this:
{
"presets": [
"@preact/babel",
["@babel/preset-env", {
"exclude": [
"transform-async-to-generator"
]
}]
],
"plugins": [
["fast-async", { "spec": true }]
]
}And they'd be at the same settings. In ^this state, it's a pointless .babelrc file, but ofc this assumes the user had something worth doing.
There was a problem hiding this comment.
is that gonna take the rest of the preset-env config from @preact/babel?
There was a problem hiding this comment.
Yes @preact/babel is this entire file: https://github.com/developit/preact-cli/blob/6ba1267cb8ffbbeb94705ac6cef246bc075db161/packages/babel/index.js
Everything else you seem to be concerned about is "injected" into @preact/babel by the CLI immediately after loading it.
There was a problem hiding this comment.
so the only thing I want to know is if your example .babelrc would basically get turned into this by babel
["@babel/preset-env", {
"loose": true,
"modules": false,
"targets": {
"browsers": [
">0.25%",
"not ie 11'"
"not op_mini all"
]
}
"exclude": [
"transform-regenerator",
"transform-async-to-generator",
"transform-typeof-symbol"
]
}]and our config doesn't get completely overriden
packages/cli/package.json
Outdated
| }, | ||
| "dependencies": { | ||
| "@babel/core": "^7.0.0", | ||
| "@babel/register": "^7.0.0", |
There was a problem hiding this comment.
what about @babel/preset-env? 👀
There was a problem hiding this comment.
Oh I see what you're saying. It'd resolve but will add to be safe
# Conflicts: # packages/babel/index.js # packages/cli/babel/index.js # packages/cli/lib/lib/webpack/transform-config.js # packages/cli/lib/lib/webpack/webpack-base-config.js # packages/cli/package.json # packages/cli/tests/images/create.js # packages/cli/yarn.lock # yarn.lock
|
Does this pass @ForsakenHarmony inspection now? |
|
still don't know how I feel about also have I feel like it's best to just have this as like |
|
IE11 has more user share than Edge 17/18 as the time of writing this. I would not recommend going with that "better" not so better coverage. |
|
the difference is, ie 11 keeps us back a lot further than edge, which with that browser list probably doesn't even get special treatment |
|
I completely understand that, then the question I should have asked is: what's the purpose of preact-cli? towards production applications used by corporations, or more towards prototypes future-thinking that don't care about usage? |
What kind of change does this PR introduce?
Refactor, Feature
Did you add tests for your changes?
No, they're already a mess (again).
Summary
Better browser list
Upgraded Babel deps from
betato7.xstableExtracted Preact-specific config into
@preact/babelpackageApplied CLI-specific Babel config changes within CLI:
babelrcfast-asyncsupport (Add fast-async babel plugin by default #617)Fixed my typo artifact (
old ~> .babelrc)Does this PR introduce a breaking change?
The default
browserschanged, dropping default support for legacy browsers.. so technically, "yes" but this is going to be a major bump already.The Babel behavior should be unchanged; if anything, it'd be
betato7.xchanges.This allows non-CLI users to download & designate
@preact/babelas a Babel preset.