Less.js: ES6 및 롤업

아니요. 나는 잠시 동안 같은 라인을 따라 생각했습니다. TypeScript를 사용하는 것은 어떻습니까? 코드 힌트/실제 개체 연결을 갖는 것이 개발/기여를 더 쉽게 만들 수 있습니다. 이것이 지식 부담/장벽을 줄지는 모르겠지만.

나는 또한 파싱/AST에 es6 컬렉션을 사용한 다음 https://github.com/Benvie/harmony-collections와 같은 es5 빌드에 폴리필을 사용하는 것을 고려해야 한다는 것과 같은 맥락에서 생각하고 있었습니다. es6 환경(최신 브라우저와 마찬가지로 현재 Node.js)에서는 메모리 오버헤드가 감소하고 AST 구성이 빨라 이론적으로 구문 분석/평가 속도가 빨라집니다.

TypeScript를 사용하는 것은 어떻습니까? 코드 힌트/실제 개체 연결을 갖는 것이 개발/기여를 더 쉽게 만들 수 있습니다. 이것이 지식 부담/장벽을 줄지는 모르겠지만.

ES6 이후에는 typescript도 es6 트랜스파일러이기 때문에 es6이 typescript를 배제하지 않는다고 생각할 수 있습니다. 이것은 이후 추가 단계가 될 것입니다.

저는 개인적으로 상당한 추가 작업이나 리팩토링이 필요하지 않는 한 typescript를 권장하지 않습니다. IMO 타이프스크립트

• + typescript를 더 쉽게 아는 새로운 사람들을 위한 개발을 만듭니다.
• + 유지보수성 증가
• 
  
  • 사람들이 최소한의 타이프스크립트를 알거나 배워야 함
  
  
• 
  
  • 코드를 작성하는 데 시간이 더 오래 걸립니다.
  
  

나는 또한 파싱/AST에 es6 컬렉션을 사용한 다음 https://github.com/Benvie/harmony-collections와 같은 es5 빌드에 폴리필을 사용하는 것을 고려해야 한다는 것과 같은 맥락에서 생각하고 있었습니다. es6 환경(최신 브라우저와 마찬가지로 현재 Node.js)에서는 메모리 오버헤드가 감소하고 AST 구성이 빨라 이론적으로 구문 분석/평가 속도가 빨라집니다.

나는 그 폴리필을 사용하지 않을 것이고, 프로젝트는 죽은 것처럼 보입니다(아마도 하모니라는 이름이 죽었기 때문일 것입니다).

또한 불행히도 ES6 기본 기능이 더 빠른지 확신할 수 없습니다( https://jsperf.com/property-access-object-array-map-weakmap/6). 예를 들어 Promise 폴리필이 기본 구현보다 빠른 방법은 슬픈 일입니다.

:+1:

모든 좋은 점. ES6/Babel에서 표준화하면 특히 프로토타입 상속을 수행할 때 쓰기뿐만 아니라 읽기도 더 쉬워집니다.

jsperf 테스트에 관한 한, 그것은 실제로 공정한 예가 아닙니다. Weakmap이 해당 특정 테스트에서 더 느리게 수행될 것으로 예상합니다. 이론상으로 다양한 개체 모양과 유형을 만든 다음 평가하는 데 있어 Less가 더 나을 수 있습니다. 확실하지 않습니다. 라이브러리에 "벤치마킹 후크"를 넣지 않고도 개별 기능에 연결하여 세분화된 벤치마킹을 수행할 수 있는 곳에서 최종적으로 테스트(그리고 추가할 수 있기를 바랍니다)하고 싶은 몇 가지 좋은 라이브러리를 찾았습니다. 나는 당신이 Less.js 내의 함수에 대해 일종의 jsperf 테스트를 할 수 있도록 무언가를 설정하기를 바라고 있습니다. 현재 릴리스이며 몇 가지 종류의 테스트 .less 파일을 사용합니다. 이전에 언급했듯이 특정 사용 사례에 대해 어느 것이 더 빠른지 추측할 필요가 없습니다. 우리는 이론적으로 일부 기능 수준 대 원시 개체에서 WeakMap에 속하고 해당 위치에서 벤치마크를 실행하고 결과에 따라 결정할 수 있습니다.

@lukeapage 는 다음과 같이 썼습니다.
IMO 타이프스크립트

• + typescript를 더 쉽게 아는 새로운 사람들을 위한 개발을 만듭니다.
• + 유지보수성 증가
• 
  
  • 사람들이 최소한의 타이프스크립트를 알거나 배워야 함
  
  
• 
  
  • 코드를 작성하는 데 시간이 더 오래 걸립니다.
  
  

그리고 언급되지 않은 매우 중요한 이점 중 하나는 건너뛰는 것입니다.
TypeScript의 유형 지정 모드는 안정적인 변수 유형을 사용하도록 강제 하여 안정적인 유형 모양을 적용하여 컴파일러가 코드를 정적으로 _및_ 동적으로 분석할 수 있는 능력을 향상시켜 최적화된 코드를 _훨씬 더 나은_ 생성하고 최적화된 코드를 느린 해석 코드로 되돌립니다.

TypeScript로 이동하는 것이 ES6으로 이동하는 것보다 더 많은 기여를 할 것입니다.

입력 모드라는 것은 금지된 Any?를 의미합니까?

나는 작은 프로젝트에서 그것을 시도했고 나는 도처에 주석을 가졌습니다.
트랜스파일러가 매우 똑똑하지 않기 때문에 많은 코드를 작성해야 합니다.

얼마나 많은 변수에 변이된 변수 유형이 있는지 확실하지 않습니다. 그래서..
성능상의 이점이 눈에 띌 것이라고 확신하지 못했습니다.

@rjgotten TypeScript 를 사용하지 않았지만 좋은 점입니다. TypeScript에 intellisense/autocomplete 환경을 사용하는 경우 변경 사항을 적용할 때 유형/객체 모양을 완성하므로 실제로 새로운 기여자에게 도움이 될 수 있습니다. 적절하게 설계되면 코드 변경에 기여하는 누군가에게 일종의 자체 문서화/익숙화/오류 방지 도구 역할을 할 수 있습니다. 그러나 그 열쇠는 아마도 TypeScript 디자인에 있을 것입니다.

전반적으로 성능상의 이점이 있습니까? 결정하기가 더 어렵습니다. 그것은 캔버스보다 더 예술가입니다.

내 자신의 프로젝트에 TypeScript를 사용하는 것을 목표로 하고 있지만 @lukeapage 에 더 동의하는 경향이 있을 것입니다. 왜냐하면 여기에 있는 우리 중 누구도 TypeScript 전문가가 아닌 한 효과적으로 사용할 수 있을지 확신이 없기 때문입니다. 그것의 처음에.

또한 ES6으로 이동한다고 해서 앞으로 TypeScript를 사용하는 것을 막을 수는 없습니다. Microsoft/Google의 목표는 TypeScript 2.0을 ES6 상위 집합으로 만드는 것이므로 항상 ES6/Babel로 시작하고 나중에 적절한 유형을 추가하고 TypeScript 변환기로 전환할 수 있습니다. 내 의심은 TypeScript가 변환된 언어를 "승리"할 것이라는 것입니다. 단지 컴파일 시간/자동 완성 이점이 유형이 지정되지 않은 JavaScript보다 훨씬 크기 때문입니다. 그래서... TypeScript를 사용하는 것이 불가피하다고 생각하지만 그렇다고 해서 바로 사용해야 하는 것은 아닙니다.

언젠가 Less에 대한 다른 아키텍처 접근 방식에 대해 논의하고 싶습니다.

입력 모드라는 것은 금지된 Any?를 의미합니까?

아니요. 일반적으로 유형이 지정된 변수를 사용합니다. 일반적으로 Any의 사용을 금지할 수 _수_ 있지만, 타이핑 시스템을 만족시키기 위해 많은 코드 팽창을 초래하는 경향이 있기 때문에 (적어도 실질적으로) 나쁜 생각입니다.

그러나 함수에서 유형이 지정된 매개변수를 사용한다는 것은 호출자(적어도 TypeScript로 작성된 호출자)가 주어진 유형을 _반드시_ 존중해야 함을 의미합니다. 이는 유형이 지정된 함수를 사용하여 적절한 경우 Less 컴파일러의 내부 작업에서 유형 안정성을 보호하고 특히 중요한 함수가 잘 최적화되도록 보장할 수 있음을 의미합니다. (잊지 마세요. JS 엔진은 일반적으로 기능 수준에서 최적화됩니다...)

작업 시작 - https://github.com/less/less.js/tree/rollup

꽤 멋진 작품. 토론에 대한 Germaine, 나는 코드를보고 빨리 발견했습니다.

if (typeof index === 'number') {   

AFAIK 유형의 온전성 검사는 TypeScript에서 절대 필요하지 않습니다. 값의 유형을 확인하기 위해 문자열 비교를 수행할 때마다 런타임에 인덱스 유형을 문자열로 변환하는 경우 그런 일이 추가될 수 있습니다. TypeScript에서 인덱스를 전달한 함수에 대한 호출이 있었지만 해당 형식이 숫자가 아닌 경우가 있고 인덱스만 _accepted_ 숫자인 경우 형식이 일치하지 않아 컴파일 시간에 함수가 실패합니다. 이러한 검사가 더 비쌀 때 런타임에 테스트됩니다.

반면에 이것은 고립되고 드문 예일 수 있습니다. 관련성이 있어 보였던 것은 내가 발견한 것뿐입니다.

명시적 유형의 가장 큰 장점은 더 강력한 도구를 사용할 수 있다는 것입니다. 함수를 호출하거나 재정의하는 모든(그리고 유일한) 위치를 찾는 것은 단지 키보드 단축키입니다. 사용 가능한 객체가 어떤 기능을 하는지 찾는 것은 작업이 필요 없으며 컴파일러가 더 많은 오류를 생성하기 때문에 리팩토링이 더 안전합니다. 또한 새로운 코드베이스를 더 쉽게 배울 수 있습니다. 큰 그림을 보고, 코드의 어느 부분이 의존하는지 알아내거나, 실행하지 않고 코드 흐름을 따르는 것은 자바보다 자바에서 더 어렵습니다(예를 들어). 유형 편집기가 더 강력하기 때문입니다.

아직 TypeScript를 사용하지 않았기 때문에 도구가 그만한 가치가 있을 만큼 성숙했는지 모르겠습니다. javascript의 장점은 모두가 알고 있고 TypeScript는 덜 알려져 있다는 것입니다.

전반적으로 더 큰 리팩토링이나 거대한 새 기능을 계획한다면 TypeScript로의 전환이 합리적이라고 생각하지만 작은 버그를 수정하는 동안에는 너무 많은 작업이 필요할 수 있습니다.

더 큰 리팩토링이나 거대한 새 기능을 계획한다면 TypeScript로의 전환이 의미가 있다고 생각하지만 작은 버그를 수정하는 동안에는 너무 많은 작업이 필요할 수 있습니다.

이것이 사실일 수 있으며 실제로는 @lukeapage 가 이미 작업을 수행했기 때문에 그가 이 시점에서 최종 결정을 내려야 한다고 말하고 싶습니다. :-)

이봐, 이것에 대해 : 사람들에게 코드베이스가 변경되고 있음을 알리기 위해 우리가해야 할 일이 있습니까? 그렇지 않으면 병합 충돌이 발생할 것이라고 가정합니다.

아니, 너무 많은 충돌이 없어야 합니다. 첫 번째 단계는 es6 모듈일 뿐입니다.
파일을 옮기면 babel이나 typescript를 투명하게 추가할 수 있습니다.

안녕, 얘들아, 지금은 어때?

나는 이 일을 할 수 있다. @matthew-dean 풀 리퀘스트를 수락하시겠습니까?

@alexlur 확실히! 내 유일한 관심사는 3.x 분기에 대한 리팩토링과 병합 충돌이 발생하지 않는 것입니다. 따라서 거기에서 분기/분기하는 것이 좋습니다. 또한 이 문제가 작성되었으므로 이제 src/ 및 dist/ 를 사용하는 잘 정립된 규칙이 있습니다. 그러나 lib/ 는 때때로 src/ 로 사용되므로 이름을 바꿀 필요가 없을 것입니다.

또한 테스트에서 lib/ 가 아닌 빌드를 사용하도록 Gruntfile을 약간 다시 작성해야 합니다. (브라우저 테스트가 하는 일은 dist/ test/ 에서 빌드하는 것입니다. dist/ 폴더는 새 릴리스를 위한 특별한 Grunt 작업입니다. 테스트할 때 빌드해야 합니다. test/ ) 그렇게 한 후 테스트를 통과하는 한 괜찮을 것입니다.

@matthew-dean 안녕하세요. 리팩토링을 완료했지만 새로 빌드된 파일에서 테스트를 실행하도록 Gruntfile을 구성하는 방법을 모르겠습니다.

내가 할 수 있는 일은 변경 사항을 별도의 분기로 병합하고 테스트 통합에 대해 보는 것입니다. 나는 단지 당신의 변경 사항을 빠르게 살펴보고 있었습니다. 내가 틀렸다면 정정해 주지만 at-rule 가 assignment 노드가 잘못되었습니까? 아니면 Github가 그것을 보여주는 방식을 엉망으로 만들었습니까?

잘 잡았습니다. 잘못된 파일을 사용했습니다.

less.js가 지원해야 하는 브라우저/Node.js의 최소 버전이 있습니까? Node.js는 Promise (0.12 이후)에 대해 상당히 좋은 지원을 제공하는 반면, 브라우저 사용은 일반적으로 어쨌든 이미 최신 브라우저 버전을 실행하고 있는 개발자를 위한 것입니다.

편집하다:

Less.js는 모든 최신 브라우저(Chrome, Firefox, Safari, IE11+ 및 Edge의 최신 버전)를 지원합니다.

Internet Explorer 11에만 Promise 가 내장되어 있지 않습니다.

@alexlur
브라우저 내 버전의 Less의 경우 less.Promise 속성을 만들고 기본적으로 window.Promise 로 설정하는 것이 좋습니다. 그런 다음 Less가 less.Promise 를 통해 Promise 클래스를 사용하도록 합니다.

이렇게 하면 최신 브라우저 사용자와 Less가 로드되기 전에 Promise가 전역적으로 폴리필된 사용자는 모든 것이 마법처럼 작동하게 됩니다. 그리고 전 세계적으로 폴리필을 원하지 않거나 어떤 이유로든 허용되지 않는 사용자는 작은 추가 단계로 작업을 수행할 수 있습니다. 실제로 Less를 사용하기 전에 선택한 Promise 구현을 less.Promise 에 수동으로 할당하기만 하면 됩니다.

@rjgotten @alexlur Less.js에는 이미 Promise 폴리필이 이미 설정되어 있습니다. 거기에서 추가 작업을 수행할 필요가 없습니다. 대부분의 코드는 다음 패턴을 사용합니다.

https://github.com/less/less.js/blob/55380d49e96a6ed561cac4d13a774830aa3c17a3/lib/less/import-manager.js#L5

노드 측에서 이 문제가 아직 열려 있습니다. https://github.com/less/less.js/issues/3121

그러나 피드백이 없고 상당히 적당한 양의 기여자가 있기 때문에 현재로서는 Node 4+가 갈 길이라고 말하고 싶습니다. 이를 반영하기 위해 문서/테스트를 업데이트해야 합니다.

@matthew-dean 별도의 분기로 병합할 준비가 되어 있어야 합니다.

@alexlur 감사합니다! 조만간 보려고 합니다. 아마도 다음 주에 있을 것입니다(다른 누군가가 그것을 확인할 여유가 없는 한).

이 문제는 최근 활동이 없었기 때문에 자동으로 오래된 것으로 표시되었습니다. 더 이상 활동이 없으면 폐쇄됩니다. 귀하의 기여에 감사드립니다.

TypeScript로 리팩토링 된 포크 를 만들었습니다.

TypeScript로 리팩토링된 포크를 만들었습니다.

@glixlur 😮 와우, 모든 테스트가 통과되었나요? 그리고 dist/ 에 동일한 less.js를 빌드합니까?

@matthew-dean 아직 작업 중이지만 브라우저용 빌드에는 일일 드라이버로서 문제가 발생하지 않았습니다. 기술적으로 롤업을 사용하면 성능 면에서 우위를 점할 수 있지만 백업할 데이터가 없습니다.

@less/core 일회성 변환을 위해 이것을 자동화할 수 있는지 확인하기 위해 조사해야 합니다. - https://github.com/lebab/lebab

@matthew-dean 완료되면 풀 리퀘스트를 보내 드리겠습니다.

@glixlur 오! 좋습니다. 이전 PR 에서 시간이 없다고 하셨습니다. 아직 작업 중이시라면 👍

@matthew-dean ES6으로 변환하는 것으로 제한하고 TypeScript 부분은 나중에 남겨두겠습니다.

@glixlur 제 생각에 ES6은 아마도 가장 "커뮤니티 친화적"으로 나아가는 첫 번째 단계일 것이므로 완벽합니다. 모든 사람이 TypeScript를 사용하고 있는지 확신할 수 없지만 ES6 흐름은 확실히 좋을 것입니다.

@matthew-dean 지원되는 가장 낮은 플랫폼이 Node 6과 IE11이라고 가정합니까?

@glixlur Appveyor는 현재 Node 4를 테스트하도록 설정되어 있습니다. 그러면 상황이 더 어려워질까요? 이상적으로는 노드/브라우저용 배포를 위해 src/ 폴더를 lib/ (및 브라우저의 경우 dist/ ) 폴더로 (대체) Babel 변환합니다. 그래서 나는 Babel이 ES5로의 트랜스파일 작업의 대부분을 하고 있다고 가정합니다.

완료 되었지만 테스트가 작동하도록 해야 합니다. PhantomJS는 더 이상 사용되지 않으며 ES5 이후에는 지원하지 않습니다.

@glixlur 좋아요 ! Re: PhantomJS, 정말로 Chromy와 같은 것으로 대체되어야 합니다. 참조: https://github.com/less/less.js/issues/3240

@glixlur 또한 이것은 Chromy / headless Chrome 관련입니다. https://github.com/less/less.js/issues/3262

@glixlur PhantomJS 와 관련하여 - 해당 테스트는 번들 브라우저 버전에 대해 실행되며, 아마도 ES5로 트랜스파일될 것입니다. 맞습니까? PhantomJS가 ES5 출력 번들과 함께 작동하지 않는 이유는 무엇입니까?

@matthew-dean 예, 하지만 Babel 변환 파일로 PhantomJS를 실행할 때 Symbol 가 사용되는 버그가 있습니다.

@glixlur 트랜스파일된 출력에 babel-polyfill 가 필요합니다. 아직 제대로 변환되지 않고 있다는 좋은 지표입니다. 다음과 같은 문제를 참조하십시오. https://github.com/babel/babel-preset-env/issues/203

@glixlur https://babeljs.io/docs/en/babel-polyfill/

@matthew-dean babel-polyfill 는 출력 파일에 축소된 87.3KB를 추가합니다. 당신은 아마 그것을 원하지 않을 것입니다.

@glixlur
babel-polyfill 을 원하지 않는 다른 이유가 있습니다. 즉 window Array 같은 기본 유형의 프로토타입을 수정하여 전역 네임스페이스에 영향을 미친다는 사실입니다.

대신 babel-runtime 및 babel-plugin-transform-runtime 패키지를 살펴보십시오.

또한 Babel 팀은 babel-env 사전 설정 제한 언어 변환과 동일한 라인을 따라 transform-runtime 번들로 묶인 폴리필을 제한하는 작업을 하고 있습니다. 그러나 그것에 대한 그들의 작업은 아직 완료되지 않았으며 일반적으로 사용 가능합니다. 어쨌든 아직 베타 버전이므로 직접적으로 유용하지 않은 Babel 7으로 끝날 것입니다. 그러나 미래에는 확실히 바람직합니다.

@glixlur @rjgotten 아. re: Babel을 사용할 솔루션이 무엇인지 정확히 모른다는 점을 분명히 했어야 했습니다. Symbol 가 폴리필(포니필?)이 아니기 때문에 정의되지 않았기 때문입니다. 이는 IE11에서도 마찬가지입니다. 따라서 폴리필이 아닐 수도 있지만 올바른 Babel 설정을 사용하면 범위가 지정된 Symbol 정의를 제공해야 합니다. 그래서 아마도 최소 브라우저 버전이 문제일까요?

올바른 Babel 설정을 사용하면 범위가 지정된 Symbol 정의를 제공해야 합니다.

정말 그럴 것이다.
이러한 설정은 babel-polyfill 에 의존하는 대신 $ transform-runtime 플러그인과 Symbol 와 같은 새로운 내장 기능에 대한 별칭을 삽입하는 기능을 사용하는 것과 같습니다.

phantomjs는 더 이상 사용되지 않아야 합니까?

죽었다고 생각하면?
아마 그렇습니다.

@glixlur 참조: https://github.com/less/less.js/issues/3240

변환이 완료되고 병합되었습니다! 참조: https://github.com/less/less-meta/issues/32

Welp, 이번 주에 JavaScript의 Class 가 단순히 함수 프로토타입에 대한 구문 설탕이 아니라 이 문제를 일으켰다는 것을 배웠습니다: https://github.com/less/less.js/issues/3414

아이러니하게도 나는 2주 전에 Less와 관련이 없는 또 다른 코드로 똑같은 일을 겪었고 그 생각을 분명히 기억합니다.

이런, Less에 대한 ES6 변환이 이러한 유형의 문제를 일으키는지 궁금합니다.

음: 질문에 답이 나온 것 같은데요?

나는 @matthew-dean님, 당신의 작업에 불만을 쏟아붓는 폭풍우를 부러워하지 않습니다. 당신은 그 상황을 처리해야 내 동정이 있습니다. :웃다:
운 좋게도 아무도 종말을 고하지 않았고 질서 있게 처리된 것 같습니다.

@rjgotten lol 내 말은, 어떻게 그런 것을 예상할 수 있단 말인가? 가장 안전한 방법은 전혀 변환하지 않거나 클래스를 사용하지 않는 것이지만 코드베이스를 덜 장황하게 만듭니다(음, 잠재적으로 더 정리할 기회가 많습니다). 기술적으로 (과거) Less와 less-loader 통합은 API를 잘못 사용했기 때문에(문서화되지 않은/지원되지 않는 API 사용 사용) 이는 그들 부분의 실수였습니다. 빌드 실패를 일으키는 비주요 포인트 릴리스.

예를 들어 누군가가 라이브러리의 프로토타입을 해킹하는 경우 방어적으로 코딩하는 방법은 무엇입니까?

🤷‍♂

@rjgotten

기술적으로, 나는 변환 후 두 개의 베타 버전을 출시했지만... 아무도 그들의 파이프라인에 Less 베타를 가지고 있지 않습니다. 따라서 Less와 통합되고 테스트를 실행하는 800,000개의 저장소를 테스트할 방법이 없습니다. NPM 종속성을 사용하면 실제로 거기에 놓고 무엇이 중단되는지 확인해야 합니다.

미래에 우리가 할 수 있는 한 가지는 테스트에 더 큰 Less 종속 항목을 추가하는 것입니다.

내가 할 수 있었던 또 다른 일은 그것을 메이저 버전으로 출시하는 것이지만.... 기술적으로 (의도적인) 주요 변경 사항이 없습니다. 즉, 지원되는 기능이 동일하고 일부 버그 수정이 포함되어 있습니다. .. 나도 몰라, 이것은 까다로운 것이었다.

응. 까다로운 일이었습니다.

.next 태그에 무언가를 추가하고 사람들이 이를 사용하여 빌드 파이프라인을 테스트하도록 알릴 수 있었던 것 같습니다. 그러나 과거의 경험에 따르면 그런 종류의 일은 일반적으로 들리지 않습니다.

어느 쪽이든, 메이저 버전이든 아니든, 당신은 아마도 "한번 해보기"만 하고 무엇이 중단되는지 볼 수밖에 없게 될 것입니다.

하지만 오해하지 마십시오. 리팩터링은 매우 좋은 기능입니다. 앞으로 나아가면 일반적으로 유지 관리 부담이 줄어들 것입니다.

예를 들어 누군가가 라이브러리의 프로토타입을 해킹하는 경우 방어적으로 코딩하는 방법은 무엇입니까?

당신은 말 그대로하지 않습니다.

사람들이 C#의 비공개 멤버에 액세스하기 위해 신중하게 조정된 런타임 방출 IL이 부 릴리스에서 중단된다고 불평하는 것과 같습니다. 내부 문제에 간섭하는 경우 구매하려는 항목을 알아야 합니다. :웃다:

@rjgotten 리팩토링에 대해 말하자면...

..... Less 코드베이스에서 시간이 지남에 따라 발견한 것 중 하나는 AST의 개체에 약간/미묘한 돌연변이가 있는 곳이 여러 곳 있다는 것입니다. 여기에 새 속성이 있습니다/여기에 인스턴스에 메서드가 추가되었습니다. JavaScript에서는 원하는 대로 언제든지 변경할 수 있기 때문에 병합한 기능을 사용하여 이 작업을 수행한 적이 있음을 완전히 인정합니다. 해당 속성을 문서화/정의했는지 여부.

TypeScript와 최신 JS가 답이 될 것인지에 대한 토론이 있었습니다. 유형이나 명확한 개체 인터페이스가 없으면 문서의 양이 많지 않거나 JSDoc으로도 해결할 수 없는 방식으로 Less 코드베이스를 추론하기가 매우 어렵다는 것을 깨달았습니다.

JSDoc에 적절한 유형이 있는 경우 TypeScript linting을 허용하도록 새 파이프라인을 설정했지만 입력에 JSDoc을 사용하는 것은 TypeScript보다 더 장황하고 시각적으로 시끄럽고 TS가 JSDoc 주석만으로는 지원하지 않는 일부 입력 기능이 있습니다. . TS가 무료로 제공하는 이러한 문제 중 일부를 해결할 수 있는 도구의 JSDoc/ESLint 조합은 없습니다.

그래서 제가 말하고자 하는 것은 작년에 TypeScript를 크게 사용하고 Less 코드베이스에서 몇 년을 보낸 후 Less가 어떻게 작동하는지 파악하는 혼란/절망/학습 곡선의 95%라고 말할 수 있습니다. 객체에 컴파일 타임 유형이 적용된 경우 피했습니다. 저는 종종 중단점을 설정하고 파일에 정의된 방식 대신 개체의 속성이 _actually_ 무엇인지 파악하는 데만 디버거에서 많은 시간을 보냈습니다.

예를 들어 평가 중에 Ruleset 노드의 paths 속성에 의존하는 Less에는 여러 기능이 있습니다. 이 생성자 에서 paths 속성이 무엇인지, 어떤 모양을 갖게 될지 알려주실 수 있나요? (힌트: 거기에 없기 때문에 할 수 없습니다.)

TypeScript(공통 tsconfig 설정 사용)에서는 이것이 허용되지 않습니다. 컴파일조차 되지 않을 것입니다. paths 의 모양을 지정해야 하고 그 안에 정확히 무엇이 들어갈지 지정해야 합니다. 그러면 코드베이스를 탐색하는 사람에게 명확하고 구체적인 문서(및 코드 힌트)가 제공됩니다.

그래서 저는 이 시점에서 "TypeScript는 고려해야 할 대상입니다"라는 생각에서 "공개 프로젝트가 TypeScript에 없으면 큰 기술적 부채가 있는 것입니다."라는 생각으로 바뀌었습니다. 나는 본질적으로 소비 가능성과 유지 관리 가능성을 해결하는 데 도움이 되기 때문에 오픈 소스 저장소 없이는 시작하지 않을 것입니다. 여전히 명확한 문서가 필요하지만 최소한 매우 명확하고 응집력 있는 코딩을 시행합니다.

여기에서 어디로 가야할지, 앞으로의 고충을 예방할 방법에 대해 생각하는 것입니다.

_( 부록 : 명확하지 않은 경우를 대비하여 저는 Less 코드베이스에서 다른 사람의 역사적 작업을 100% 비난하지 않습니다. 제가 제안하고, 승인을 받고, 코드베이스에 병합된 많은 것들이 있습니다. "아, 그렇게 하지 않았더라면 좋았을 텐데." 아니면 다르게 했으면 좋았을 텐데. 그리고 지금 내가 깨닫고 있는 것들을 확실히 추가해서 유지 관리 가능성에 부정적인 영향을 미쳤을 수도 있습니다. 모두가 최선을 다했습니다.)_

@matthew-dean
JSDoc에 적절한 유형이 있는 경우 TypeScript 린트를 허용하도록 새 파이프라인을 설정했지만 입력에 JSDoc을 사용하는 것은 TypeScript보다 더 장황하고 시각적으로 시끄럽고 TS에서 JSDoc 주석만으로는 지원하지 않는 일부 입력 기능이 있습니다. . TS가 무료로 제공하는 이러한 문제 중 일부를 해결할 수 있는 도구의 JSDoc/ESLint 조합은 없습니다.

실제로; JSDoc 지원이 유형 추론에 대해서도 마찬가지라는 문제를 겪었습니다.
운 좋게도 .js .d.ts 선언 파일을 사용할 수 있습니다. TypeScript 전체를 사용하거나 컴파일러가 필요하지 않습니다.

선언 파일로 작업하는 것이 훨씬 더 어려웠지만 최신 버전의 TypeScript 컴파일러는 .d.ts 파일과 .js 파일이 모두 이름이 지정되어 있는 한 자동으로 .d.ts 파일을 나란히 연결합니다. 똑같다.

그것이 당신이 찾고있는 것일 수 있습니다.

@rjgotten 이것이 Less의 코드베이스와 어떻게 잘 작동할 수 있는지에 대해 좀 더 설명(또는 좋은 리소스를 알고 있는 경우 링크)할 수 있습니까? 에서와 같이 파일 수준별로 파일에서 이 작업을 수행하는 방법은 무엇입니까? .js .d.ts 파일이 있습니까? 아니면 그룹화합니까?

.d.ts 파일을 가지고 있는 것과 소스에서 TypeScript를 사용하는 것의 장점은 무엇입니까? 파일에서 해당 유형을 정의하는 대신 .d.ts 파일을 만드는 데 시간을 소비하는 이유는 무엇입니까?

@rjgotten 오늘 Chevrotain 개발자와 이야기를 나누었는데 그가 하는 일은 TS에서 개발하는 것이라고 합니다. 하지만 실제로는 api.d.ts 파일을 별도의 관심사로 관리하고 있습니다. 이렇게 하면 소스 파일의 유형 변경(예: 트리 노드)이 API 유형 파일의 명시적 변경 없이 공개 API를 투명하게/보이지 않게 변경하지 않습니다.

그런 다음 그는 내부 유형과 공개 API 유형이 일치한다는 주장과 함께 테스트를 사용합니다. -> https://github.com/SAP/chevrotain/blob/master/packages/chevrotain/test_integration/definitions/api_type_checking.ts#L1 - L2

Chevrotain의 방식은 공개 API가 실수로 변경되지 않도록 하는 좋은 방법입니다. 해당 수준의 보호가 필요하다고 생각되는 경우 매우 강력합니다. 그러나 약간의 오버헤드도 발생합니다.

.js 타이핑을 담기 위한 $ .d.ts 선언 파일의 사용에 관하여:
사실 둘 다입니다.

나란히 진행하면 자동 제안, 린팅 등을 위해 TypeScript 컴파일러가 지원하는 모든 IDE가 자동으로 입력을 선택합니다. Afaik _또한_ 나란히 입력하는 스크립트를 node_modules 에서 가져오면 꽤 좋습니다.

api.d.ts 와 같은 단일(세트) .d.ts 파일에 입력한 다음 JSDoc을 사용하여 선언된 유형을 명시적으로 가져올 수도 있습니다. TypeScript의 JSDoc 지원에는 가져오기 구문을 사용하는 특수한 @typedef 가 있습니다. 예

/**
 * <strong i="17">@typedef</strong> {import("../api.d.ts").MyType } MyType
 */

패키지를 배포하기 전에 트랜스파일 단계를 거쳐야 하는 경우 단일 번들 타이핑 파일을 사용하는 것이 좋습니다. 이러한 경우 사용자가 실제로 require() 또는 import {} 가 되는 것은 더 이상 원본 소스 파일이 아닙니다. 즉, 나란히 입력하는 것의 이점을 얻지 못할 것입니다.