안녕하세요 오늘은 자동화 테스트 코드에 대한 이야기를 해보려고 합니다.

 

5개의 TC(Test Case)가 있습니다. 테스트 방식은 직접하는 매뉴얼 테스트도 있을 것이고 성능,부하 등등 

 

여러가지가 있지만 말씀드리고자 하는 부분은 단순 Unit Test 혹은 API 테스트 같은 부류들 처럼 코드단에서

 

이루어지는 부류를 말씀 드리고자 합니다.

 

예전에 제가 사용 하였던 2가지의 패턴 방식을 보여드리려고 합니다.  현재는 또 이러 저러한 구조를 통해서 변경 

 

하고 있습니다.

 

독립적 실행이 필요한가?

어떠한 프로그램에 따라서는 아닐수도 있고 맞을수도 있습니다. 저같은 경우는 JS 로 돌아가는 환경이 최근에 많았었는데요 JS의 경우는 .js파일을 읽어들이면서 코드라인이 실행됩니다. JIT(Just In Time) 라고도 하죠 그렇기 때문에 어떠한 현상이 발생되는 현상은 

 

함수 b로 인해 실행되지 못한 c함수 

 

위와 같은 문제가 발생하게 됩니다. TestCase를 3개를 만들었지만 2번째 케이스로 인해서 3번째 케이스가 돌지 못하는 현상이 발생하게 되는 것이지요

 

1차적으로 간단하게 수정할수 있습니다.

function a(){
	console.warn('Success');
}
function b(){
    try{
        var test = "";
        test.push('test'); // Error 
    }
    catch(err){
	    console.log(err);
    }
}
function c(){
	// not Execution 
	console.warn('function C Success');
}

a();
b();
c();

try catch 로 묶어 주게되면 

문제없이 catch 로 핸들링이 되며 다음코드로 자동으로 넘어가게 되겠죠 

 

하지만 실제로 업무에서 사용되는 케이스는 10단위도 아니고 100단위도 아니고 1000단위가 넘어가게됩니다.

 

코드 단에서 할수 있다면 최대한 많은 케이스를 확보 하여 커버리지를 올릴 수 있기 때문이죠 

 

1. TC(TestCase) 내용으로 함수 연결하여 실행하기

TC(TestCase)의 경우 유니크한 값을 가지기 마련입니다. 함수명을 해당 키 값으로 하여서 실행시키는 방법입니다.

var testRepo = [
  {tc:"a",contents:"a를 테스트합니다.",result:"block"},
  {tc:"b",contents:"b를 테스트합니다.",result:"block"},
  {tc:"c",contents:"c를 테스트합니다.",result:"block"},
]

var testFunctionRepo = {
  run:function(repo){
    var _this = this;
      repo.forEach(function(item,index){
        try{
          _this[item.tc]();
        }
        catch(error){
          console.error(error);
        }

      });
  },
  a:function(){
    console.warn('Success');
  },
  b:function(){
    var test = '';
    test.push('test'); // Error
  },
  c:function(){
    // not Execution 
    console.warn('function C Success');
  }
}
testFunctionRepo.run(testRepo);

결과 :

성공

 

tc에서 만들어진 유니크한 값을 통해서 함수를 작성해놓았습니다.

 

그후엔 run 이라는 함수를 하나 만들어서 해당 함수에서 tcRepo 를 직접 순환시에 나오는 유니크 값을 함수를 불러와서  실행을 하는 구조입니다. 그렇기 때문에 try catch 문은 하나만 있을수 있죠 

 

위에서는 테스트를 변경하진 않았는데 해당의 내용도 가능합니다. 

 

2. TC(TestCase) 내용에 함수가 들어있는 경우 

이번에는 Repo 안에 함수가 들어있는 경우입니다. 


var testRepo = [
  {tc:"a",contents:"a를 테스트합니다.",result:"block",run:function(){
		console.warn('Success');
  }},
  {tc:"b",contents:"b를 테스트합니다.",result:"block",run:function(){
		var test = '';
		test.push('test'); // Error
  }},
  {tc:"c",contents:"c를 테스트합니다.",result:"block",run:function(){
		// not Execution 
		console.warn('function C Success');
  }},
]
function run(repo){
	if(repo && repo.length===0){
		return ;
       }
	repo.forEach(function(item,index){
		try{
			item.run();			
        }
		catch(error){
			console.error(error);
        }
    });
}

run(testRepo);

 

위에 있는 경우와 조금 다른 케이스입니다.  Repo 안에 직접 run 이라는 함수를 직접 내장 하였는데요 

Repo 안에 전부 있기 때문에 run 을 오브젝트를 통해서 실행할 필요는 없어 보여 run 함수를 따로 작성 하였습니다.

이렇게 2가지를 알아보았는데 해당 방식을 놓고 보면 좋아 보이는거 같기도하고 하지만 

기본적인 방법입니다. 뭔가 더 정형화되거나  확장성에는 용이 하지 않죠 

 

여러명이 작업할때 좀 더 모듈단위 로 세분화가 되거나  하여야 할 것으로 보입니다. 이부분에 대해서는

 

다음포스팅에 다시 작성 하겠습니다.

cd 등으로이동할때 tab키를 눌러서 이동하게 되면 해당 에러 메시지가 나타납니다.

아 이게 무슨 버그인가 무슨일인가 생각 하게 됩니다. 탭은 자동완성 기능으로만 알고 있었거든요

 

우선 해당 내용을 순서대로 보게 된다면 "장치" 라는 점에 주의깊게 보셔야 합니다.

 

리눅스 명령어 중에서 df 라는 명령어가 있습니다.  파일 시스템의 디스크 공간을 확인 하는 명령어인데요

 

-h 옵션을 같이 사용하여서 확인해 봅시다.

(-h 옵션은 -human-readable 로 사람이 보기 편하게 해주는 옵션입니다. )

 

df(disk free) - h 명령어로 확인해 보면

 

centos-root 가 꽉찬 모습 

예상이 맞았습니다. 화면에 보이시는 것처럼 /dev/mapper/centos-root 라는 공간이 꽉찼습니다.

 

마운트 위치는 / 로 되어있는데요 그냥 루트라는 뜻입니다.

 

여기서 조금 엉뚱한 생각을 해보자면요 ( 이렇게 생각 하시는 분이 가끔 있을수 있습니다. )

 

/dev/mapper/centos-root 로 들어가면 되는건가?

 

아니지 Mounted On 의 위치가 / 이니까 이 경로가 문제일거야 라고 생각 해볼수 있습니다.

 

전자와 후자 둘다 확인 해보겠습니다

/dev/mapper/centos-root 접속

 

네 아닙니다. 

보시면 디렉토리는 아니고 파일도 아니고 심링크로 연결되어있는 것으로 보입니다.

제가 원하는건 centos-root 인데요 -> ../dm-0 이라고 되어있네요

파일에 써있다기 보단 disk 에 들어가 있는 형태입니다. 

 

정확히 말하자면 내 하드드라이브가 1024G라면 그중 50G가 root라는 파티션에 들어가있다는 뜻이 되는데요

 

그럼 여기서 centos-root 는 어디부분을 뜻할까요

 

centos-root 를 비우는 방법

1차적으로 생각 해본다면 /var 와 /usr 부분을 1차적으로 백업하거나 지우시면 됩니다.

 

간단하게 생각해본다면 /usr의 경우는 크게 바뀌는 부분이 없을 것으로 기대됩니다.

 

/var에서 대부분 git 로그나 WAS(JEUS)의 Access.log 등이 차기 때문이죠

 

/ 로 이동합니다.

 

/var와 /usr가 범인인지 확인하기 위해서는 이번에는 df 가 아닌 du 라는 리눅스 명령어를 사용합니다. 

 

du (disk Usage) 

 

우선 var를 봅시다. 위치들이 다 루트기 때문에 루트 권한으로 봐야 합니다.

 

sudo -s du -sh /var

네 범인이 맞았네요 /usr도 같이 볼까요

sudo -s du -sh /usr

두 친구가 용량의 원인이 맞았던 것 같습니다. 확실히 로그를 쌓고 있는 var 쪽에 처리를 해주어야 할 것 같습니다.

 

/var 경로 정리 

/var 폴더 안에는 무수한 디렉토리 존재합니다.  어떤 폴더가 어느정도 용량을 쓰는지 매번  du -sh 를 할수 없는 노릇

 

편하게 볼수 없는 방법을 찾아보았습니다.

 

sudo -s du -h --max-depth=1

현재 폴더 경로에서 누가 용량을 많이 먹고 있는지 한번에 확인이 가능 합니다. 

예상대로 log가 30G를 먹고 있네요  마찬가지로 로그도 종류가 많기 때문에 같은 방법으로 찾아 봅니다.

Jenkins 로그가 너무 많았네요...

해당 로그로 접근을 위해서는 sudo -s 가 아닌 su 로 Root 아이디로 접근합니다.

 

그리고 해당 로그를 다시 /home 위치에 백업 합니다.

mv jenkins.log /home/oqa/logBackup

백업을 한 후에는 이제 하나로 묶여있는 backup로그들을 나눠 줄 필요가 있습니다.

split -l 300 jenkins.log part_jenkins

300줄씩 로그를 짤라서 part_jenkins 프리픽스를 붙여서 파일을 새로 만듭니다.

다음 이렇게 로그를 분리 하였고 (현재는 로그 백업용 이지만  다음 포스팅에서는 조금 더 유연한 관리를 해보겠습니다.)

 

결과 ( 비워지지 않음 )

보시면 cetnos-home은 분명 늘어났는데!!!

 

centos-root는 그대로 50G를 유지하고있습니다.

 

이유가 뭘까요..

 

원인 

Jenkins 로그였기 때문에 기존에 Jenkins가 실행되고 있었기 때문입니다.

 

Jenkins를 종료 하게되면 그 순간에 제대로된 영역이 잡히게됩니다.

 

이제 다시  시작해주면 끝입니다.

 

/etc/init.d/jenkins start

 

감사합니다.

최근에 QT 를 사용하게 될 일이 있어서 이에 대해서 기록차 글을 한번 끄적 거려 봅니당

 

web 쪽 QA를 하고 있다보니 우리 제품으로 제작된 페이지가 잘 구동되는지에 대해서 검증을 하게 됩니다.

 

IE( 10, 11 )  , Chrome, FireFox 최근에는 Safari 도 추가하려는 움직임이 스물스물 

 

하지만 이번에는 조금 특이한 케이스가 있었습니다.  제품을 구매하는 고객사에서는 webView를 사용하여 

 

모든 프로그램들이 구동이 되는 환경 인것 이였습니다! 그렇기 때문에 우리도 그에 맞춰서 우리의 제품 들

 

또는 QA에서 제작되어있는 페이지들이 정상적으로 구동이 되는지를 확인 해보아야 합니다.

 

WebView의 경우는  webkit이라는 엔진을 사용하기 때문에 Chrome이랑 같겠지! 라고 생각 하면 오산입니다.

 

어찌됐든 C++프로그램에 올라가는 형태로 진행이 되는 것 이기 때문에 어떠한 동작에 대해서는 다른 결과를

 

가져올수 있기 때문입니다.

대표적으로 webView에서는 openWindow가 되지않습니다.

정정합니당 Default Settings으로 webView에서 openWindow가 되지않습니다.

탭을 하나 새로 켜야하지만 C++ 프로그램에서는 없을 수 있기 때문이죠

 

재빠르게 QA가 만들어놓은 페이지를 검증 후 우리회사의 제품 을 검증해야 하는데 처음 하게되는 제품에 대해서는

 

빠르게 체크리스트를 작성하여 Pass, Fail 을 기록 하여 전달하는 것이 업무 전달에 조금 빠르게 진행 할수 있을

 

거라고 생각 하였습니다.

 

하지만 사용해야 하는 버전은 5.9.X 버전 qt 코드 작성 예시를 찾다 보면 webView의 코드가 단순하게 나와있습니다.

 

(QT를 설치하는 작업은 생략 하였습니다. 단순하게 

 

Main.cpp

#include <QtGui>
#include <QtWebKit>

int main(int argc, char** argv) {
    QApplication app(argc, argv);
    QWebView view;
    view.show();
    view.setUrl(QUrl("http://google.com"));
    return app.exec();
}

Main.pro

QT += webkit
SOURCES = example.cpp

 

이와 같이 말이죠  이렇게 한번에 된다면 정말 좋겠지 만요 QT는 5.5 이후로 webView가 빠져있습니다. 

 

두둥... 그렇습니다. qmake 사용시 Unkown Module(s) webkit 을 보게 됩니다.

 

5.9 버전에서는 webView가 없기 때문에 마찬가지로 QTCreator에서도 WebView는 존재하지 않습니다.

 

그래서 동작하지 않게 되는데 webkit을 깔거나 이것저것 여러가지 시도를 해보았지만 webkit을 따로 붙이는 작업을

 

하다가 더 빨리 웹뷰를 띄워야 한다는 요청이 있었어서  5.9.X Documentation QT를 들어가서 확인해 보니 

 

webEngine을 이용한 방법이 있었습니다.

 

Main.cpp

#include <QWebEngineView>
#include <QApplication>
#include <QUrl>

int main(int argc, char ** argv){
	
    QApplication app(argc,argv);
    
    QWebEngineView *view = new QWebEngineView();
    view->setZoomFactor(0.7); // 배율 조정 API 테스트 를 편하게 하기 위해 추가
    view->load(Qurl("테스트 url"));
    view->show();
    
    
    return app.exec();
}

MainSample.pro

QT += webenginewidgets widgets core gui

... 

실행 결과

 

 

** 포스팅에서 제외된 부분 

필요한 Module들에 대한 에러 메시지가 나타날 경우 해당 관련 제품들을 설치 하였습니다.

 

감사합니다.

 

프로비저닝(provisioning)

사용자의 요구에 맞게 시스템 자원을 할당,배치, 배포해 두었다가 필요 시 시스템을 즉시 사용할 수 있는 상태로 미리 준비 하는것

매시업 (Mashup)

웹으로 제공하고 있는 정보와 서비스를 융합하여 새로운 소프트웨어나 서비스, 데이터베이스 등을 만드는 것

 

INFRASTRUCTURE PLATFORM (IaaS)

 AWS EC2 GLE(Google Cloud Engine) Azure Vms

 

CONTAINER PLATFORM (CaaS)

GKE ECS ACS

 

APPLICATION PLATFORM (Paas / aPaaS) 

Heroku PCF Jelastic

 

FUNCTION PLATFORM (FaaS)

AWS Lambda GCF Azure Functions

 

SOFTWARE PLATFORM(SaaS) 

Salesforce Oracle SAP

 

 

+as a service

 

 

 

 

 

 

 

 

안녕하세요 저번 블로그 포스팅 에서는 TypeScript를 입문하기 위해서 한글 공식 문서와 함께 vscode상에서의 프리티어 

 

설정 등을 하여서 정말 기본중의 기본 튜토리얼만 진행 해보았습니다.

 

// TypeScript Documentation korea Language 

https://typescript-kr.github.io/pages/tutorials/TypeScript%20in%205%20minutes.html

 

TypeScript 한글 문서

TypeScript 한글 번역 문서입니다

typescript-kr.github.io


그런데 제가 하고자 하는 거랑은 맞지 않았던 것이 있습니다.

TypeScript를 JS로 빌드 하지만 JS만으로는 한계가 있기 때문에 기본적으로 html 파일과 css파일이 필요합니다만

 

ts만 따로 빌드하기엔 뭔가 깔끔하지 않는 느낌이랄까요 그래서 같이 한꺼번에 할수 없을까 하여

 

이것저것 찾아 보았습니다. 이왕하는거 sass도 쓰고 이것저것 해보는것이 더 좋은 것 같아서

 

webpack v4

 

웹팩 요즘 많이들 이야기 나오는 번들러 입니다. 해당 번들러에 ts-loader ( TypeScript Loader ) 를 사용하면 같이 이용해볼수 있을 것 같더군요

 

물론 각자 검색해서 공식홈으로 가도 되시겟지만   아래 일단 공유 !

https://webpack.js.org/

 

webpack

webpack is a module bundler. Its main purpose is to bundle JavaScript files for usage in a browser, yet it is also capable of transforming, bundling, or packaging just about any resource or asset.

webpack.js.org

webpack 구조

위의 사진을 보시면 딱 원하는 것들이 나왔습니다.

저는 좌측에

 

.ts .js .scss .png, .jpg .html   .....   -> .html,.css,.js .jpg.png ... 이외 리소스 정도로 사용할수 있겠네요 

 

일단 webpack 을 설치 하여야 합니다.

 

npm i -D webpack webpack-cli webpack-dev-server

webpack , webpack-cli, webpack-dev-server 입니다. 

그리고 같은 프로젝트에 에 webpack.config.js 파일을 생성 합니다. 

webpack 기본 세팅을 하기 위해서는 여러가지 방법이 필요한데요

 

 

const path = require('path');
const HtmlWebPackPlugin = require('html-webpack-plugin');
const MiniCssExtractPlugin = require('mini-css-extract-plugin');

module.exports = {
    name:'myTypeScript-setting',
    mode:'development', // "production" | "development" | "none"
    devtool:'eval',  // source-map   hidden-source-map
    resolve:{
        modules:['node_modules'],
        extensions:['.ts','json','.jsx','.scss','.css','.js'],
        alias:{
            "@gdlComponents":path.resolve(__dirname,'src/gdlComponents'),
            "@gdlCommonLayout":path.resolve(__dirname,'src/gdlComponents/CommonLayout'),
            "@gdlCommonWidget":path.resolve(__dirname,'src/gdlComponents/CommonWidget'),
            "@gdlUtils":path.resolve(__dirname,'src/gdlUtils'),
            "@gdlConfig":path.resolve(__dirname,'src/gdlConfig/_config'),
            "@userCSS":path.resolve(__dirname,'src/css/userCSS')
        }
    },
    entry:{
        index:['./src/index.ts']
    }, 

    module: {
		rules: [
			{
				test: /\.ts$/,
                use: ['ts-loader'],
                exclude:["/node_modules"]
            },

            {
                test:/\.html$/, // html loader
                use:[
                    {
                        loader:'html-loader',
                        options:{minimize:true}
                    }
                ]
            },
            {
                test:/\.scss$/,
                use:[
                    MiniCssExtractPlugin.loader,
                    'css-loader',
                    'sass-loader',
                ]
            },
            {
                test:/\.(png|svg|jpg|gif)$/,
                use:[
                    {
                        loader:'file-loader',
                        options:{
                            name:'[hash].[ext]', // [path][name].[ext]?[hash] result : path/to/file.png?e43b20c069c4a01867c31e98cbce33c9
                            outputPath:'res/images',
                            publicPath:'res/images'
                        }
                    }
                ]
              
                    
            },
        
		]
    },
    
    plugins:[
        new HtmlWebPackPlugin({
            template:'./src/index.html',
            filename:'./index.html'
        }),
        new MiniCssExtractPlugin({
            filename:'[name].css',
            chunkFilename:'[id].css'
        })
    ],
    optimization:{},
    output:{
        path:path.join(__dirname,'./dist/src'),
        filename:'[name].js'
    },
  
}

현재 제가 사용하고 있는 webpack.config.js 입니다. 

https://github.com/lgance/gdlComponent

 

lgance/gdlComponent

my TypeScript Play Ground. Contribute to lgance/gdlComponent development by creating an account on GitHub.

github.com

해당 코드는 위의 주소에서 계속 최신화를 하고 있습니다. 받으신 후에 

npm i

npm audit fix

npm start

하시면 dist폴더에서 index.html 을 더블클릭으로 결과물 확인이 가능합니다

 

코드 를 보여준 이유는 뭔가 기본적으로 딱 돌아가는 형태를 확인하면 이해하는데 있어서 훨씬 빠르게 이해할수 있기

 

때문입니다. 제가 만약에 계속 작성되는 코드 때문에 이글을 읽을 당시에 이해하기 힘들정도로 

 

코드가 많아 질수 있기 때문에 

 

2f75f71e41738ca5b3dcb85d521c9980bfcac647 < commit id  의 커밋을 받아서 확인해 보시면 될것 같습니다.

 

해당 커밋의결과 물은 

 

이와 같이 나타납니다. 하단의 img태그가 있긴 한데 이거는 아직 테스트용으로 index.html 에서 img태그 를 지우시면

 

문제없이 화면에 채워서 나타날 겁니다. 

 

다시 webpack.config.js 로 돌아오게 되면

 

기본적으로 중요하게 봐야 할 부분은

 

 

entry 

 

시작점을 뜻합니다. 현재 프로젝트에서 시작하여야 하는 소스코드의 위치를 뜻합니다. 저는 

./src/index.ts 로 작성이 되어있는데요 

 

해당 위치를 시작점으로 잡습니다. 

현재 프로젝트 구조인데요 보시면 ./src를 저는 기준으로 실 소스 코드를 작성하기 때문에 entry 포인트를 위와같이 잡았습니다.

webpack 명령어를 실행시 config를 확인하여서 src/index부터 번들링할 코드를 찾게 됩니다.

 

output

 

엔트리가 시작 점이였다면 아웃풋(output)은 끝점 어디로 나와야 하는가 입니다. 위의 사진에서 보면

 

좌측에 있는 여러가지 번들링되어야 하는 리소스(webpack 에선 모두 모듈이라고합니다.) 들이 이리저리 엮여있는데 

 

이 시작점은 entry 로 이미 지정이 되어있습니다.  그럼 다 묶인상태에서 어디로 나올것인가 에 대한 지정을 하는곳이 이

 

ouput 이라고 할수 있습니다.

 

위의 코드에 보시면 output은

 output:{
        path:path.join(__dirname,'./dist/src'),
        filename:'[name].js'
    },

로 되어있으니 현재 프로젝트 위치에서 ./dist/src에 번들링된 파일들이 나오게 될 것으로 보입니다. 

 

파일네임에 지정된 name값은  entry 에서 지정한 이름이 들어가게 됩니다.

entry:{
        index:['./src/index.ts']
    }, 

index라는 값이 들어갈 것 같습니다

 

현재까지 entry 와 output에 대해 작성하였는데 webpack 은 사실 더 복잡하고 세밀하게 제어가 됩니다. 

 

현재는 entry 와 output이 1개씩이지만 entry 를 여러개 만들어서 output을 대응시킬수도 있습니다. 

 

해당 작업은 추후에 작성해보면 될 것 같습니다. 

 

module

 

모듈 은 이제 중간 단계라고 보실수 있습니다. Entry 에서 시작점을 잡았고 해당 위치에서 엮어야 할 파일들을 다 엮은 

 

후에 output의 설정대로 dist(저는 dist로 설정)로 번들링된 결과물을 만들어 냅니다. 그러면 중간에 entry 로 부터

 

읽어들인 파일들을 어떤식으로 불러서 처리해야 할까? scss css ts이런것들은 그냥 부른다고 되는게 아니라 기존에는 

 

빌드 과정을 거쳐서 하였던 것들인데 이것들을 중간에 처리 해주는 과정이 있는데 이부분을 module 에 기록하며

 

각각의 파일들을 불러서 처리 해주는 녀석을 Loader (로더) 라고 합니다. webpack 은 파일들을 처리해주어야 하는데

 

JS만 동작하기 때문에 이부분들을 로더를 통해서 진행이 됩니다. 로더는 test 와 use로 동작하게 되는데 이중

 

test 어떠한 파일을 로딩할건지 지정 

 

use 해당 파일을 읽어 올 로더를 설정 

 

저는 일단 읽어와야 할 파일들이 html,ts scss, 이외 이미지 파일들 이 있기 때문에

 

ts-loader, html-loader, css-loader, sass-loader, file-loader를 사용 하였습니다. 이외에도 노드에서 sass를 읽어오기 위한

 

node-sass등 여러가지 디펜던시 등을 추가하였습니다. 아래 그림 참고

 

** npm i -D 로 설치 하셔야 합니다. 런타임에선 사용하지않기 때문에 devDependencies로 넣어야 합니다.

현재 사용하고있는 모듈들이며 모듈에 대해서 각각 따로 자료 조사를 해보면 더 쉽게 나오겠지만 간단하게만 설명을 하자면

 

css-loader  - css파일을 import하여 사용할수 있게 도와줌

style-loader - css를 style태그를 만들어서 index.html 에 추가를 도와줌

sass-loader - scss 파일을 css로 변환 ( node-sass 와 같이 사용하여야 함)

file-loader,url-loader - 리소스 파일들을 변환

html-loader - html 파일을 변환

html-webpack-plugin - html 파일을 변환시 해당 플러그인을 통하여 추가 변환

mini-css-extract-plugin - css파일을 새로하나 만들어서 번들링 (이게없을 경우 index.css가 생기지않아 한쪽에 css가 너무 많아져 성능 문제가 생김)

ts-loader - .ts파일들을 js로 변환 (tsconfig.json 을 참고하여 컴파일)

 

이제 맨 위에 있는 module중 ts-loader부터 말씀드리겠습니다.

 

 

ts-loader

 

말그대로 entry 포인트 부터 ts파일들을 찾아서 지정할 부분입니다. 보시면

( TypeScript를 안쓴다면 babel이 대체됩니다.  babel-loader 를 사용하시면 됩니다. )

 

{
     test: /\.ts$/,
     use: ['ts-loader'],
     exclude:["/node_modules"]
},

 

test - 어떠한 파일들을 로딩할지 정규식형태로 .ts로 되어있습니다.

user : ts-loader 해당 읽어들인 파일들을 어떠한 로더로 읽어올지 입니다. test에서 ts를 읽었기 때문에 ts-loader를

        선택하여 읽어 옵니다.

exclude: 선택옵션인데 읽지 말아야할 경로를 지정했습니다. 저는 node_modules를 했습니다.

 

 

html-loader

 

html을 만난다면 해당 html을 읽어서 번들링할때 포함해줍니다.

{
  test:/\.html$/, // html loader
    use:[
      {
      loader:'html-loader',
      options:{minimize:true}
      }
 	]
},

options : minimize:true  -> html 파일들을 공백 개행없이 만들어 줍니다. ( 더 많은 옵션은 html-loader 를 참조 )

 

이외에 모듈들도 위와같은 형태를 가지며

 

추가적으로 사용하고 있는 plugins하나만 소개해드리면

 

plugins

 

MiniCssExtractPlugin 을 사용하고있는데 이는 npm 에서 새로 설치 한후에 require로 가져와서

 

아래와같이 플러그인을 사용할수 있습니다. 

 

entry -> module( loader )  ->  plugins  -> output  와같이 중간단계에서 추가적으로 해주어야 할 작업들에 대해서

 

이와같이 webpack 자체적으로 추가하여 사용할수 있습니다.

 plugins:[
        new HtmlWebPackPlugin({
            template:'./src/index.html',
            filename:'./index.html'
        }),
        new MiniCssExtractPlugin({
            filename:'[name].css',
            chunkFilename:'[id].css'
        })
    ],

 

해당 설정들 말고 위에 resolve나 devtool, mode name 등에 대한 옵션들은 하나씩 찾아가며 하면 어렵지 않은 부분이라

 

이번 포스팅에서는 제외하였습니다.  webpack 이 한번에 이해가 안될때 보일러 플레이트 같은 프로젝트를 돌려보면

 

이해가 좀 쉬울거라고 생각되어집니다. 위의 공유된 github에서 clone후 실행해보면서 이해할수 있으면 좋을 것 같습니다.

 

 

+ Recent posts