В настоящее время я вижу то же самое и ищу решение.Это то, что я нашел до сих пор, и может быть полезно.
В нашем случае мы используем babel для переноса нашего кода, и, глядя на код, созданный babel, мы видим, что генераторы переносятсядля браузеров, на которые нацелен список браузеров, прочитайте @babel/preset-env
.Итак, в качестве начального теста мы удалили @babel/preset-env
из нашей сборки dev и протестировали локально в Chrome 70. Генераторы больше не переносились, и мы могли успешно устанавливать точки останова в VSCode.
Таким образом, для нас решение заключалось в том, чтобы не переносить для сборок dev, а переносить для наших целевых браузеров для производственных сборок.
Для справки, вот конфигурация babel, которую мы использовали для тестирования этого решения:
module.exports = {
presets: [
'@babel/preset-react'
],
plugins: [
[
'@babel/plugin-proposal-object-rest-spread',
{
useBuiltIns: true
}
],
'@babel/plugin-proposal-class-properties',
'@babel/plugin-transform-modules-commonjs'
],
env: {
production: {
presets: [
[
'@babel/preset-env',
{
debug: false,
useBuiltIns: 'usage'
}
]
],
plugins: [
'@babel/plugin-transform-runtime'
]
}
}
}
Мы можем установить BABEL_ENV=production
в любых производственных сценариях npm, для которых мы хотим ориентироваться на поддерживаемые браузеры.
{
"name": "testapp-ui",
"version": "1.0.0",
"private": true,
"scripts": {
"build": "rm -rf dist && mkdir dist && NODE_ENV=production BABEL_ENV=production npm run build:webpack",
"build:dev": "rm -rf dist && mkdir dist && NODE_ENV=development npm run build:webpack",
"build:webpack": "webpack --progress --debug",
...