Видимо, это больше для низкоуровневых экосистем (Go/Rust).
Высокоуровневость тут значения не имеет, любому проекту в целом не помешает воспроизводимость. Думаю, все были бы счастливы, если бы любой проект просто запускался бы с одной кнопки в любой IDE / редакторе. Я использую Nix для любой разработки: недавно, например, форкнул клиент Telegram и вайбкодил кое-что для личных нужд на Swift, постоянно использую для Go, JS и Python. Иногда запускаю локально один проект на Rust (хотя я его особо не знаю, но мне иногда надо запустить его локально). Ещё одно преимущество конфигов Nix в том, что их можно генерировать с помощью LLM — и легко проверить на адекватность (сразу видно если там ставится что-то не то, чего не понять, если ИИ-агент выполняет `apt get` и что-то устанавливает, особенно, не дай бог, если это происходит на моём компьютере).
Однако Java/Kotlin — это скорее всего Android, и в Android мире многое завязано на экосистему Android Studio, мало кто использует что-то другое, потому что в AS лучше дебаггеры, эмулятор и всё такое. А эмулятор, к сожалению, из контейнера не запустишь, поэтому будут сложности. Всё остальное можно, но в контексте Android просто не очень нужно, потому что можно нажать одну кнопку в AS и всё тоже заработает "с одной кнопки".
В стеках, где у людей зачастую разные предпочтения по редакторам, чтобы не навязывать одну конкретную IDE (ну не все хотят использовать JetBrains, или VS Code, или Neovim — это всё вкусовщина), нужен некоторый адаптер, который свяжет IDE с контейнером так, чтобы это работало "с одной кнопки". В этом и заключается суть стандарта DevContainers — еще один уровень абстракции сверху, исключительно для удобства, и он совершенно необязателен для тех, кому он не нужен.
Главная идея DevContainers как раз в том, чтобы корректно работали интеграции с LSP, дебаггерами, форматтерами и прочим.
Главная сложность — это что "снаружи" (вне контейнера) у вас одна файловая система, и путь до файла, скажем, `$HOME/myrepo/file.js`, в то время как внутри контейнера это `/app/file.js`. Чтобы, когда Ваша IDE / редактор отправляют запрос в LSP, нужный файл был действительно найден, они должны жить в одной файловой системе.
Поэтому нужно запускать и саму IDE / редактор внутри контейнера. Все современные популярные IDE / редакторы клиент-серверные (среди них точно VS Code, Zed, JetBrains, и даже Vim/Neovim). Вся суть DevContainers в том, чтобы установить "серверную часть" IDE внутрь контейнера, и тогда LSP, дебаггеры и прочие интеграции будут прекрасно работать.
Установить VS Code Server можно и ручками в контейнер, просто это придётся делать, а DevContainers это делают за тебя.
Всё вышеперечисленное делается одной кнопкой — это и есть роль стандарта DevContainers — быть адаптером между IDE и контейнером.
Зависит от того, в Ваших ли руках исходники и сборка. Если Вы дебажите свой код, у вас есть доступ к конфигу сборщика (например, Webpack) и самому коду, то есть следующие опции:
1. Поставить `debugger` прямо в коде, а также в Chrome на вкладочке Sources там где сам код, есть кнопка "Pretty print". Названия переменных и функций буду по-прежнему сложночитаемыми, но с `debugger` всё же получше, чем просто с `console.log`, можно будет проследить хотя бы порядок выполнения кода.
Разобраться, как включить source-maps в Вашем сборщике (например, Webpack), и пользоваться ими. Такое также уместно как временная мера, если баг встречается только в production режиме (только не забудьте потом снова отключить, чтобы не грузить ненужные файлы).
В случае же, если код не Ваш и он обфусцирован/минифицирован, то тут всё становится намного сложнее и уже называется "reverse engineering". Это материал на отдельную статью)
Высокоуровневость тут значения не имеет, любому проекту в целом не помешает воспроизводимость. Думаю, все были бы счастливы, если бы любой проект просто запускался бы с одной кнопки в любой IDE / редакторе. Я использую Nix для любой разработки: недавно, например, форкнул клиент Telegram и вайбкодил кое-что для личных нужд на Swift, постоянно использую для Go, JS и Python. Иногда запускаю локально один проект на Rust (хотя я его особо не знаю, но мне иногда надо запустить его локально). Ещё одно преимущество конфигов Nix в том, что их можно генерировать с помощью LLM — и легко проверить на адекватность (сразу видно если там ставится что-то не то, чего не понять, если ИИ-агент выполняет `apt get` и что-то устанавливает, особенно, не дай бог, если это происходит на моём компьютере).
Однако Java/Kotlin — это скорее всего Android, и в Android мире многое завязано на экосистему Android Studio, мало кто использует что-то другое, потому что в AS лучше дебаггеры, эмулятор и всё такое. А эмулятор, к сожалению, из контейнера не запустишь, поэтому будут сложности. Всё остальное можно, но в контексте Android просто не очень нужно, потому что можно нажать одну кнопку в AS и всё тоже заработает "с одной кнопки".
В стеках, где у людей зачастую разные предпочтения по редакторам, чтобы не навязывать одну конкретную IDE (ну не все хотят использовать JetBrains, или VS Code, или Neovim — это всё вкусовщина), нужен некоторый адаптер, который свяжет IDE с контейнером так, чтобы это работало "с одной кнопки". В этом и заключается суть стандарта DevContainers — еще один уровень абстракции сверху, исключительно для удобства, и он совершенно необязателен для тех, кому он не нужен.
Главная идея DevContainers как раз в том, чтобы корректно работали интеграции с LSP, дебаггерами, форматтерами и прочим.
Главная сложность — это что "снаружи" (вне контейнера) у вас одна файловая система, и путь до файла, скажем, `$HOME/myrepo/file.js`, в то время как внутри контейнера это `/app/file.js`. Чтобы, когда Ваша IDE / редактор отправляют запрос в LSP, нужный файл был действительно найден, они должны жить в одной файловой системе.
Поэтому нужно запускать и саму IDE / редактор внутри контейнера. Все современные популярные IDE / редакторы клиент-серверные (среди них точно VS Code, Zed, JetBrains, и даже Vim/Neovim). Вся суть DevContainers в том, чтобы установить "серверную часть" IDE внутрь контейнера, и тогда LSP, дебаггеры и прочие интеграции будут прекрасно работать.
Установить VS Code Server можно и ручками в контейнер, просто это придётся делать, а DevContainers это делают за тебя.
Всё вышеперечисленное делается одной кнопкой — это и есть роль стандарта DevContainers — быть адаптером между IDE и контейнером.
Взгляните на лидеров индустрии, вложивших бесконечные деньги в ИИ и сильнейших ИИ инженеров.
Например, Microsoft и их великолепная Windows 11.
Или AWS, падающий уже раз в пятый за последние два месяца. Вы припоминаете такую частоту 2-3 года назад?
То-то же, времена поменялись, прогресс!
Slop-войска
Зависит от того, в Ваших ли руках исходники и сборка. Если Вы дебажите свой код, у вас есть доступ к конфигу сборщика (например, Webpack) и самому коду, то есть следующие опции:
1. Поставить `debugger` прямо в коде, а также в Chrome на вкладочке Sources там где сам код, есть кнопка "Pretty print". Названия переменных и функций буду по-прежнему сложночитаемыми, но с `debugger` всё же получше, чем просто с `console.log`, можно будет проследить хотя бы порядок выполнения кода.
Разобраться, как включить source-maps в Вашем сборщике (например, Webpack), и пользоваться ими. Такое также уместно как временная мера, если баг встречается только в production режиме (только не забудьте потом снова отключить, чтобы не грузить ненужные файлы).
В случае же, если код не Ваш и он обфусцирован/минифицирован, то тут всё становится намного сложнее и уже называется "reverse engineering". Это материал на отдельную статью)