Repository navigation
Conversation
*Total -- 1,894.42kb -> 1,859.03kb (1.87%) /images/hw_lite/PingpongPracticalartsLite.png -- 98.39kb -> 90.86kb (7.66%) /images/hardware/codingboxv2.png -- 1,796.02kb -> 1,768.17kb (1.55%) Signed-off-by: ImgBotApp <ImgBotHelp@gmail.com>
- 함수 안에서 런타임 에러가 발생하면 경고 토스트는 뜨지만 에러가 발생한 블록에 빨간 테두리가 표시되지 않아 사용자가 원인 블록을 찾을 수 없었습니다 🔍 - 원인: 한 번의 실행에서 서로 다른 블록의 에러가 여러 번 보고될 때, 매번 Entry.Func.edit 을 다시 호출해 cancelEdit → initEditView 로 함수 보드가 재렌더되면서 앞서 적용한 activated 클래스가 지워집니다 🧩 - 마지막 보고가 하이라이트를 복구하지 못하면 경고만 남고 테두리는 사라진 상태로 끝납니다⚠️ - 이미 같은 함수를 편집 중이면 Entry.Func.edit 을 다시 호출하지 않도록 가드를 추가했습니다 🛠️ - Entry.Func.edit 이 실행된 경우에는 Block 인스턴스가 교체될 수 있으므로 블록 참조 대신 id 로 다시 조회하도록 했습니다 ♻️ - block.getCode() 가 없는 경우에 대한 방어 코드를 함께 추가했습니다 🛡️ - 함수 블록이 포함된 작품에서 에러 발생 시 해당 블록에 테두리가 표시되는 것을 확인했습니다 ✅
기존에는 github.run_number 에서 기준점 313 을 빼서 dev 번호를 만들었다. 이 방식은 워크플로 실행 횟수에 묶여 있어 정식 버전이 올라가도 카운터가 리셋되지 않는다. 4.0.23 이 master 로 배포되면 base 는 4.0.24 로 바뀌지만 run_number 는 그대로 누적돼 있어 4.0.24-dev.1 이 아니라 4.0.24-dev.5 같은 번호가 나온다. 같은 구성을 쓰는 entry-tool 에서 이 문제가 실제로 터져 이미 발행한 버전을 unpublish 하고 다시 올려야 했다. entryjs 는 아직 어긋나지 않았으므로 지금 바꿔 unpublish 없이 전환한다. 이제 npm 에 올라간 <base>-dev.N 중 가장 큰 N 에 1 을 더해 채번한다. base 가 바뀌면 그 base 의 dev 가 하나도 없어 번호가 자동으로 1 부터 다시 시작하고, 발행 이력을 근거로 삼으니 재publish 가 거부될 일도 없다. 기준점 하드코딩이 사라져 워크플로 실행 횟수와 무관해진다. 검증한 채번 결과: - 4.0.23 -> dev.2 (4.0.23-dev.1 이 이미 발행돼 있음) - 4.0.24 / 4.1.0 / 5.0.0 -> dev.1 (해당 base 의 dev 가 없어 리셋) Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
ci: dev prerelease 채번을 npm 발행 이력 기준으로 변경
_startContentRender 는 리렌더마다 필드를 새로 만들면서 _contents 를 비우지만, 버려지는 필드가 슬롯 안 블록의 뷰에 걸어둔 _posObserver/_sizeObserver 는 끊지 않았음. 슬롯 안 블록은 params 에 살아있어 그 옵저버도 함께 남고, 블록을 교체할 때 bumpAway 가 0.15초 뒤 위치를 바꾸면 이미 버려진 필드가 updateValueBlock(undefined) 으로 깨어나 params 를 빈 슬롯 기본값(10)으로 덮어씀. 화면은 현재 필드가 그린 것이라 정상으로 보이고 toJSON/copy 만 params 를 읽으므로, 저장 후 새로고침에서야 값이 바뀐 것이 드러남. _contents 를 비우기 전에 각 필드의 _destroyObservers 를 호출해 옵저버 누적을 막고, 같은 취약점이 있는 FieldOutput 에도 _destroyObservers 메서드를 추출해 적용. destroy() 는 슬롯 안 블록의 뷰까지 파괴하므로 리렌더 경로에서는 쓰지 않음. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
- 핸드셰이크가 실패해도 포트를 정리하지 않아, 같은 동글이 새로고침 전까지 재연결되지 않음 - 정체 파싱을 이름 대신 필드 위치 기준으로 바꾼다. 주소는 16진수 12자리만 받음 - 핸드셰이크에 5초 타임아웃을 두고, 실패하면 모듈이 직접 포트를 정리함 - 연결 유지 중 동글의 페어링 로봇이 바뀌면 같은 정체를 두 번 확인한 뒤 전환함 - 연결 시 모듈 번호를 '0204' + 변형바이트로 덮어쓰던 대입을 제거한다. 다른 hardwareLite 모듈은 모두 생성자에서 번호를 고정한다. 변형 바이트는 로봇마다 달라(실측 05, 00, 01) 등록되지 않은 번호가 만들어지고, 햄스터S도 0204가 되어 기종 구분이 안됨 - 검증 실패 프레임이 연속되면 정체를 다시 요청함
- 설치형 엔트리와 entry-hw는 햄스터와 햄스터S가 이미 두 항목으로 나뉘어 있는데 브라우저 연결만 하나로 합쳐져 있었다. 그 구조를 맞춤 - 한 파일에서 인스턴스 둘을 내보낸다(020401 햄스터, 020E01 햄스터S). 블록 정의는 한 벌을 공유하고, 블록 함수 32곳이 호출 시점에 인스턴스를 찾음 - 햄스터S 항목은 다른 기종을 거부한다. 문구는 로케일 넷(ko, en, jp, vn) - 기존 햄스터 항목은 두 기종을 계속 받는다. 저장된 작품에 기종 정보가 없어 대칭으로 분리하면 그 항목으로 햄스터S를 쓰던 작품이 연결 불가가 됨 - 햄스터S 사진은 구형과 좌우가 반대여서 센서 모니터 좌표를 항목별로 줌
- 타이머를 지울 때 완료 콜백을 함께 버려서, 대기 블록이 완료 표시를 기다리며 영원히 폴링했다. 햄스터S와 무관하게 현재 출고본에서도 재현됨 - 대기 계열 5개(이동, 음표, 출력, 라인트레이서, 보드)를 모두 덮음 - 벤더 모듈에서 스레드를 중단시킬 수단이 없어, 취소된 대기 블록은 완료로 처리해 다음 블록으로 넘김
변수 값이 1e+21 형태가 된 뒤 더하기 연산이 숫자 덧셈이 아닌 문자열 결합으로 처리되는 문제를 수정한다. 원인 - JS 는 |x| >= 1e21 부터 String(x) 와 Number.prototype.toFixed() 가 지수 표기를 반환한다. `변수에 O만큼 더하기`(block_variable.js)의 .toNumber().toFixed() 가 이 경계에서 "1e+21" 문자열을 만들어 변수에 저장한다. - Entry.Utils.isNumber 의 정규식이 지수 표기를 매치하지 않아, calc_basic 의 PLUS 분기가 parseFloat 로 이미 파싱된 값을 다시 문자열로 되돌린다. 같은 함수 안에서 parseFloat 와 isNumber 의 판정이 어긋나 있던 것이 문제의 실체다. 수정 범위 - utils.js 의 정규식 한 줄만 확장한다. false -> true 로 바뀌는 값은 지수 표기 문자열뿐이고 기존에 true 였던 값이 false 가 되는 경우는 없다(단조 확장). 한 글자 단위로 검사하는 입력 필터(textInput/angle) 에서도 'e' 단독은 여전히 매치되지 않아 동작이 변하지 않는다. - block_calc.js 와 block_variable.js 는 변경하지 않는다. block_variable 의 .toNumber() 를 제거하면 `변수에 더하기`와 `변수 정하기`의 표시가 갈리므로 표시 정책은 별도 과제로 분리한다. 동작 변경(QA 확인 필요) - `O이(가) 숫자인가?` 블록이 1e+21 에 참을 반환한다. - 지수 문자열을 담은 변수가 숫자 변수로 취급된다. - 파이썬 변환 시 지수 표기가 따옴표 없이 출력된다. 테스트 - test/util/isNumber.spec.js (48) 지수 표기 인정, 거부 대상 유지, 단조 확장, 한 글자 입력 필터 가드, parseNumber 프로젝트 로드 경로 - test/playground/blocks/calc_basic.spec.js (10) VOC 재현, toFixed 산출값 재계산, 글자 결합/소수점 오차/나머지 연산자 가드 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
[ImgBot] Optimize images
- 프로젝트 중단 대기 중 실행기가 다음 블록으로 이동해 잘못 강조되는 문제를 막기 위해 참조를 미리 보존했습니다 🐛 - 함수 실행기와 오류 블록 ID를 toggleStop 호출 전에 캡처하도록 변경했습니다 🎯 - Jest 테스트와 ESLint 오류 없음으로 검증했습니다 🧪
fix: 리렌더 시 버려지는 필드의 옵저버를 정리해 슬롯 값이 10으로 덮이는 문제 수정
fix: 지수 표기(1e+21)를 숫자로 인정하도록 isNumber 정규식 확장
- 로보메이션의 새 로봇 두 종. 기존 로보메이션 동글을 그대로 사용 - 삐오봇: 바퀴 두 개, 목 회전, 눈 LED, 버저 - 라쿤봇: 관절 네 개짜리 로봇 팔. 각도 지정, 좌표 지정, 티치 재생 - 블록 파일 `block_pio.js`, `block_raccoon.js` 신규 - 블록에 뜨는 글자는 각 파일의 `setLanguage()` 에 ko, en, jp, vn 네 로케일 - 로봇 동작은 `block_robomation.js` 에 `PioRobot`, `RaccoonRobot` 으로 추가 - 하드웨어 목록 등록은 `hardware/index.js` 가 자동 처리. 등록 파일 수정 없음 - 로봇 사진 `images/hw/pio.png`, `images/hw/raccoon.png`
…nt at 12 - Add SERVO_PIN(4) sensor type, ko/en templates, block menu entry and runcoding_led_set_servo block (0~180 clamp), same behaviour as the original runcoding servo block - Lower falling star/flower/snow max count from 20 to 12 to match the firmware MAX_OBJECTS change (frees SRAM on the Uno) Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
[로보메이션] 삐오봇, 라쿤봇 하드웨어 블록 추가
[로보메이션] 브라우저 연결 기능 - 햄스터S 추가 및 햄스터 연결 안정성 개선
feat(hardware): Jikko Basic 수정 및 Animal, Darae, Drone 블록 추가
Add servo motor block to Runcoding_display and cap OLED animation cou…
Dependabot 미해결 경고 114건 중 코드 변경 없이 해결 가능한 건만 적용한다. 소스 코드는 전혀 건드리지 않으며, package.json 버전 범위와 pnpm-lock.yaml만 바뀐다. 주요 해소 항목 (critical 8건 전부 포함): - form-data 2.3.3→2.5.6 / 4.0.5→4.0.6 (안전하지 않은 난수로 boundary 생성, CRLF 주입) - shell-quote 1.8.3→1.10.0 (quote() 개행 미이스케이프) - websocket-driver 0.7.4→0.7.5 (프로토콜 혼동을 통한 메시지 변조) - socket.io-parser 3.3.4→3.3.6, 3.2.0 제거 (패킷 디코딩 검증 미흡, 메모리 고갈) socket.io-client 2.5.0 이 기대하는 3.3.x 라인 유지를 위해 ~3.3.6 으로 고정 - xmlhttprequest-ssl 1.5.5→1.6.3 (인증서 검증 미흡, 임의 코드 실행) - minimist 0.0.10/1.2.0→1.2.8 (프로토타입 오염) - lodash 4.17.23→4.18.1 (_.template imports 키를 통한 코드 주입, _.unset/_.omit 오염) - fast-uri, js-yaml, minimatch, brace-expansion, node-forge, picomatch, path-to-regexp, flatted, ws, serialize-javascript, browserslist 등 high 다수 검증: - pnpm 9 (CI와 동일) 기준 `--frozen-lockfile` 설치 성공, lockfileVersion 9.0 유지 - `pnpm prod` 프로덕션 빌드 성공, 번들 구문 유효 - entry.css 는 caniuse 데이터 갱신으로 cssnano 선택자 병합이 달라져 319바이트 늘었으나 선언 6,630개 기준 유효 차이 0건으로 의미상 완전히 동일함을 확인 - eslint 결과 baseline 과 동일, `pnpm test` 통과 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
karma 4.4.1 이 끌고 오던 구형 하위 트리가 critical 2건을 포함한 다수 경고의 출처였다. karma 는 npm script 어디에서도 실행되지 않는 유휴 개발 도구이며(테스트는 jest 사용), karma.conf.js 는 v6 와 호환되는 표준 옵션만 사용하므로 설정 변경이 필요 없다. 동반 해소: - socket.io 2.1.1 → 4.8.3, engine.io 3.2.1 → 6.6.10 - ws 3.3.3 제거 (메모리 고갈 DoS) - xmlhttprequest-ssl 1.5.5 제거 (인증서 검증 미흡 / 임의 코드 실행, critical) - socket.io-parser 3.2.0 제거 (패킷 디코딩 검증 미흡, critical) - log4js 4.5.1 → 6.9.1, flatted 2.0.2 제거, tmp 0.0.33 → 0.2.7, cookie 0.3.1 제거 이 커밋만 되돌리면 karma 는 4.x 로 복귀하고 앞 커밋의 오버라이드는 그대로 유지된다. 검증: `--frozen-lockfile` 설치 · `pnpm prod` 빌드 · `pnpm test` · eslint 모두 통과. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
전 저장소(소스·설정·스크립트·CI)를 훑어 참조가 하나도 없는 패키지만 골라 제거한다. dependencies: - file-saver 참조 0건. 과거 b97eb4e, 68fcf3b 에서 소스 사용처가 제거됨 - html-webpack-template 참조 0건. serve.js 는 직접 작성한 example/*.ejs 를 씀 devDependencies: - @babel/eslint-plugin .eslintrc 의 plugins 는 ["prettier"] 뿐. 쓰이는 건 @babel/eslint-parser - prettier-eslint 참조 0건 (prettier·eslint-plugin-prettier 와 다른 패키지) - @types/pixi.js typings:null 스텁. pixi.js 5 가 자체 타입을 제공 - karma, karma-chai, karma-mocha, karma-chrome-launcher, mocha, chai 죽은 설정 파일: - Gruntfile.js 구조적으로 실행 불가. 4번째 줄 require('google-closure-compiler') 가 모듈 로드 시점에 throw 한다. grunt·grunt-cli·google-closure-compiler·grunt-* 6종이 package.json·node_modules·lockfile 어디에도 없다. - karma.conf.js 유일한 소비자가 Gruntfile.js:60. 게다가 Entry/EntryStatic/filbert/Test 전역을 로드하지 않아 수동 실행도 실패한다. 위 두 파일이 karma/mocha/chai 6종의 유일한 참조처였다. npm script 와 GitHub Actions 어디에도 karma·grunt·mocha 호출이 없다. 누락 의존성 보정: - rimraf ^6.1.3 추가. "clean": "rimraf ./dist" 가 선언 없이 호출하며 hoisting 운에 기대고 있었다. 효과: 의존성 트리 1,419 → 1,310 (109개 감소). socket.io 2.x·engine.io 3.x·log4js 4.x 등 karma 가 끌고 오던 레거시 체인이 통째로 사라졌다. 검증: --frozen-lockfile 설치·빌드·테스트·clean 전부 통과. 빌드 산출물은 직전 커밋과 바이트 단위로 동일(entry.js 35,432,816 / entry.min.js 17,994,161). Dependabot 경고 해결 85/114 유지. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
webpack_config/common.js:125 의 externals 는 react, react-dom, @entrylabs/tool, entry-paint, @entrylabs/sound-editor, @entrylabs/legacy-video 뿐이고 이들은 package.json 에 아예 없는 런타임 전역이다. 즉 선언된 의존성은 전부 dist/ 에 번들되며, 소비자가 별도로 설치할 필요가 없다. 또한 files 필드로 배포되는 src/playground/ 경로가 직접 import 하는 외부 패키지는 buffer, crypto-js, lodash/* 뿐임을 확인했다. 아래 10개는 그중 하나도 아니다. 이동 대상 (dependencies -> devDependencies): - jest 테스트 러너 (scripts.test) - webpack 빌드 - copy-webpack-plugin 빌드 플러그인 - html-webpack-plugin 빌드 플러그인 - worker-loader webpack 로더 (common.js:37, 인라인 구문 사용처 없음) - autoprefixer postcss 플러그인 - postcss-flexbugs-fixes postcss 플러그인 - @types/crypto-js, @types/hammerjs, @types/isomorphic-fetch TS 타입 전용 효과: dependencies 33 -> 23. 특히 jest 24 가 빠지면서 소비자 설치본에서 request(패치 없음)·tough-cookie·node-notifier·micromatch 3.x·braces 2.x·uuid 3.x 가 사라진다 — Dependabot 경고 6건어치 코드가 소비자에게 더는 전달되지 않는다. 주의: 배포 패키지의 의존성 계약이 바뀌는 변경이라 별도 커밋으로 분리했다. 검증: --frozen-lockfile 설치·빌드·테스트 통과. 빌드 산출물은 직전 커밋과 바이트 단위로 동일(35,432,816 / 17,994,161 / 187,891). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
pnpm 10 부터 package.json 의 resolutions / pnpm.overrides 를 더 이상 읽지 않는다. 그 결과 CI(pnpm 9)와 개발자 로컬(pnpm 11)이 서로 다른 의존성 트리를 만들고 있었고, 기존 pixi.js 5.3.7 핀조차 로컬에서는 무력화되어 5.3.12 로 설치되고 있었다. 로컬에서 pnpm install 한 번이면 직전 커밋들의 보안 오버라이드가 통째로 날아가는 상태였다. 실측 확인: 오버라이드 위치 pnpm 9 pnpm 11 package.json > resolutions 적용 무시 package.json > pnpm.overrides 적용 무시 pnpm-workspace.yaml > overrides (+ packages) 적용 적용 변경: - pnpm-workspace.yaml 신규. 오버라이드 34개를 이전했다. packages 필드는 생략 불가 — 없으면 pnpm 이 "packages field missing or empty" 로 즉시 실패한다. karma 제거로 대상이 사라진 socket.io@^2 항목은 정리했다(35 -> 34). - package.json: resolutions 삭제(pnpm 11 이 읽지 않는 죽은 설정), packageManager "pnpm@11.26.0" 와 engines 추가. - 워크플로 2종: pnpm/action-setup v3 -> v4 로 올리고 version 입력을 제거해 packageManager 필드를 단일 진실 원천으로 삼는다. - Node 20 -> 24. pnpm 11 이 Node >=22.13 을 요구하므로 선택이 아니라 필수다. - pull-request-workflow 에는 setup-node 스텝이 아예 없어 러너 기본 Node 에 의존했다. Node 24 스텝을 추가했다. 없으면 기본값이 22.13 미만일 때 pnpm 11 이 그 자리에서 죽는다. allowBuilds: pnpm 10 부터 의존성 install 스크립트가 기본 차단이며, 판단을 내려두지 않으면 설치가 ERR_PNPM_IGNORED_BUILDS 로 exit 1 한다. 실제로 이 저장소에서 재현됐고(CI 가 여기서 죽는다), core-js(후원 안내 출력뿐)와 fsevents 1.2.13(NAN 구 API 라 Node 22+ 에서 빌드 실패, 없으면 폴링 폴백)을 false 로 명시했다. 검증 (pnpm 11.26.0 / Node 24.19.0): - pnpm install --frozen-lockfile exit 0, lockfileVersion 9.0 유지 - pixi.js 가 pnpm 11 에서도 5.3.7 로 고정 — 기존 잠재 버그 해소 - Dependabot 경고 해결 85/114 유지 - pnpm prod 빌드 exit 0, 번들 구문 유효, pnpm test 통과 - eslint 13,879건으로 baseline 과 동일 - entry.css 바이트 동일 + 선언 6,630개 대조 유효 차이 0건 - entry.js 가 368바이트 증가. 원인 규명 결과 pnpm 가상 스토어 경로가 바뀌면서 webpack deterministic 모듈 ID 가 재배정된 것으로, 차이나는 7개 모듈은 전부 require.context 의 ID 매핑 테이블과 webpack 런타임이다. 파일 경로는 동일하고 숫자 ID 만 다르다 — 번들 코드 자체는 같다. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Issue/10565
[fix] 함수 내부 런타임 에러 블록의 하이라이트가 사라지는 문제 수정
#3093에서 추가된 카테고리별 색상 테마(직코베이직 9색, 다래보드 4색)와 드론 단일 테마(#FF5656)를 표준 하드웨어 색으로 교체한다. - color: EntryStatic.colorSet.block.default.HARDWARE - outerLine: EntryStatic.colorSet.block.darken.HARDWARE - 드롭다운 arrowColor: EntryStatic.colorSet.arrow.default.HARDWARE 색 값만 바꾸고 팔레트·매핑·값 블록 복제 로직과 카테고리 제목 블록은 그대로 둔다. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
[하드웨어][9월 정기배포] develop <= develop-hw
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
| '이 항목은 햄스터S 전용입니다. 구형 햄스터는 목록에서 "햄스터"를 선택해 주세요. 다시 연결할 때 포트를 한 번 더 선택해야 합니다.', | ||
| foreignTitle: '다른 로봇이 연결되었습니다', | ||
| foreignDesc: | ||
| '햄스터S가 아닌 로봇이 연결되었습니다. 이 항목에서는 이 로봇을 제어할 수 없습니다. 연결을 끊고 햄스터S를 연결하거나, 목록에서 "햄스터"를 선택해 주세요.', |
Contributor
| en: { | ||
| rejectTitle: 'Not a Hamster S', | ||
| rejectDesc: | ||
| 'This entry is for Hamster S only. For the older Hamster, choose "Hamster" from the list. You will need to pick the port again when reconnecting.', |
Contributor
| 'This entry is for Hamster S only. For the older Hamster, choose "Hamster" from the list. You will need to pick the port again when reconnecting.', | ||
| foreignTitle: 'A different robot is connected', | ||
| foreignDesc: | ||
| 'A robot other than Hamster S is connected. This entry cannot control it. Disconnect and connect a Hamster S, or choose "Hamster" from the list.', |
Contributor
| 'この項目はハムスターS専用です。旧型ハムスターは一覧から「ハムスター」を選んでください。再接続の際はポートをもう一度選択する必要があります。', | ||
| foreignTitle: '別のロボットが接続されました', | ||
| foreignDesc: | ||
| 'ハムスターS以外のロボットが接続されています。この項目ではこのロボットを制御できません。接続を切ってハムスターSを接続するか、一覧から「ハムスター」を選んでください。', |
Contributor
| vn: { | ||
| rejectTitle: 'Đây không phải Hamster S', | ||
| rejectDesc: | ||
| 'Mục này chỉ dành cho Hamster S. Với Hamster đời cũ, hãy chọn "Hamster" trong danh sách. Khi kết nối lại, bạn cần chọn cổng một lần nữa.', |
Contributor
| 'Mục này chỉ dành cho Hamster S. Với Hamster đời cũ, hãy chọn "Hamster" trong danh sách. Khi kết nối lại, bạn cần chọn cổng một lần nữa.', | ||
| foreignTitle: 'Đã kết nối một robot khác', | ||
| foreignDesc: | ||
| 'Một robot không phải Hamster S đang được kết nối. Mục này không thể điều khiển nó. Hãy ngắt kết nối và kết nối Hamster S, hoặc chọn "Hamster" trong danh sách.', |
Contributor
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.