1. 前端項目怎麼手動導入依賴包
前端項目怎麼手動導入依賴包方法如下，
1.
點擊file===>project Structure===>moles
2.
點擊dependencies,再點擊右側加號,選擇第一個JARs or directories
3.
選擇下載好的依賴jar包,然後一直點擊OK即可
4.
點擊左側的項目下方的External Libraries會發現剛剛添加的jar包已經存在了
2. 怎麼學習前端開發求推薦學習路線
基礎知識
1、
HTML + CSS 這部分建議在線教程 上學習，邊學邊練.
之後可以模仿一些網站做些頁面。在實踐中積累了一些經驗後，可以系統的讀一兩本書，推薦《Head First HTML 與 CSS
中文版》，這本書講的太細了，我沒能拿出耐心細讀。你可以根據情況斟酌。
2、Javascript 要學的內容實在很多，如果沒有其他編程語言的基礎的話，學起來可能要費些力，建議看《Javascript語言精粹》，JS是一門很混亂的語言，這本書能夠幫助你區分哪些是語言的精華，哪些是糟
粕，對於語言精華，應該深入學習。糟粕部分能看懂別人寫的代碼就行，自己就不用嘗試了。
有了以上基礎，就可以進行一般的靜態網頁設計，不過對於復雜的頁面還需要進一步學習。
1、CSS。必看《精通CSS》，看完這本書你應該對：盒子模型，流動，Block，inline，層疊，樣式優先順序，等概念非常了解了。作為練習可以看下《CSS藝門之匠》這本書，它對標題，背景，圓角，導航條，table，表單等主題都有詳細的介紹。
2、Javascript。上面提到內容還不足以讓你勝任JS編程。在有了基礎之後，進一步學習內容包括：
a） 框架。
推薦jQuery，簡單易用，上手jQuery即可完成一些簡單的項目。學習方法也很簡單，照著產品文檔做
幾個頁面就行了，不用面面俱到，以後遇到問題查文檔就行了。框架可以幫你屏蔽瀏覽器的差異性，讓你能更專注與Web開發學習的精髓部分。補充： 可以使用
Codecademy 學習 Javascript，jQuery，用戶體驗真的很好（感謝 TonyOuyang ）。
b） Javascript 語言範式
。這個名字可能並不恰當，只是我找不到可以描述「面向對象」，「函數式」這個兩個概念的概念。Javascript不完全是一個面向對象的語言，它的很多
設計理念都有函數編程語言的影子，甚至說如果你不用面向對象，完全可以把它理解成一門函數式編程語言。
Javascript的很多語言特性，都是因為他具有函數式語言的特點才存在的。這部分推薦先學習面向對象的基本理論，對封裝，繼承，多態等概念要
理解，維基網路，網路會是你的幫手，另外推薦《Object Oriented
Javascript》，應該有中文版。對與函數式編程我了解的也不系統，不好多說，可以自己網路一下。
c） Javascript 語言內部機制。必須弄清如下概念：JS
中變數的作用域，變數傳遞方式，函數的定義環境與執行環境，閉包，函數的四種調用方式（一般函數，對象的方法，apply，call），以及四種調用方式
下，『this』指向的是誰。這部分內容你會在《Javascript語言精粹》中詳細了解。另外，你必須理解 json。
d） dom編程，這個Web前端工程師的核心技能之一。必讀《Dom編程藝術》，另外《高性能 Javascript》這本書中關於dom編程的部分講的也很好。
e） Ajax編程，這是另一核心技術。Ajax建議在網上查些資料，了解這個概念的來龍去脈，網路，維基網路上的內容就足夠了。真正編程是很容易的，如今幾乎所有框架都對Ajax有良好的封裝，編程並不復雜。
f） 了解瀏覽器差異性。這部分包括CSS和js兩部分，瀏覽器差異內容很多，建議在實踐中多多積累。另外對於瀏覽器的渲染模式，DOCTYPE等內容應該系統學習。
3、HTML5和CSS3 。HTML5規范已經於2014年10月28日發布了，移動端HTML5和CSS3已經得到了非常廣泛的使用，必知必會呀。
再進一階 · 代碼層面：
有了以上知識，對於大多數小型網站，你應該已經可以寫出能夠工作的代碼了。但要想成為更專業的前端，你還需繼續努力。更高的要求大概還有四方面：1）易維護，2）可測試，3）高性能，4）低流量（移動端）。
1）易維護。對於頁面你該理解『樣式』，『數據』，『行為』三者分離，對應的當然就是CSS,HTML,js。對於js代碼，你最好了解設計模式，重構，MVC等內容。
2）可測性。
3）高性能。必讀《高性能Javascript》
4）低流量。移動端關注比較多。
5）對於想要學習前端的同學，尤其是自學的夥伴，自學並非永久的，假如沒有定力的還是找個培訓機構吧。
再進一階 · 工程層面：
前端項目同樣面臨軟體生命周期的各個環節，首先是代碼管理，你必須學會使用Svn和Git。其次是代碼的構建，如今前端代碼構建已經不是簡單的壓縮一下了，需要進行依賴管理、模塊合並、各種編譯，比需要學會使用Grunt、Gulp等前端構建工具。
3. 前端工程依賴包的分類
關於 npm 包依賴，分三種情況 :
4. 前端怎麼進行組件化的開發，以及如何解決組件之間依賴
可以用webpack，目前最火的前端構建工具。只要載入loader，你想引用什麼模塊就引用什麼模塊。現在用的就是webpack+react，組件化太方便了。更多問題可以去php中文網問答社區提問
5. 模塊化需要回答系統架構的那些問題
這篇文章給大家介紹前端模塊化要解決的兩個問題分別是什麼，內容非常詳細，感興趣的小夥伴們可以參考借鑒，希望對大家能有所幫助。
前言
前端模塊化，主要是解決兩個問題「命名空間沖突」，「文件依賴管理」。
坑___命名空間沖突
我自己測試好的代碼和大家合並後怎麼起沖突了?
頁面腳本的變數或函數覆蓋了公有腳本的。
坑___文件依賴管理
明明項目需要引入的包都引進來了怎麼還報缺少包?
手動管理依賴，有天要更換某個插件，要深入代碼內部進行修改
如下圖，顯示的代碼載入，依賴關系復雜。在F.js中，分不清某個變數是來自C.js，還是E.js
兩次載入同一個模塊。比如引入了兩遍JQ
其他的坑
為了實現腳本復用，將一個很大的公用public文件引入各個頁面中，其中的某些函數，只有個別頁面用到。
某個功能的函數群函數，與另一個功能的函數群擺在一起，使用注釋來分隔。
目前解決的方法是:模塊化
命名空間：各個模塊的命名空間獨立。A模塊的變數x不會覆蓋B模塊的變數x。
模塊的依賴關系:通過模塊管理工具如webpack/requireJS/browserify等進行管理。
模塊化的基本原理解決命名空間沖突
JavaScript的缺陷，首當其沖就是全局變數。這使得每想命名一個變數的時候都要三思又三思，生怕上方無窮遠的地方有一個同事些的代碼和自己沖突。以下是一些防範方法
一、使用命名空間
代碼如下：
//定義 var mole = { name: 'rouwan', sayName:function(){ console.log(this.name) } } //使用 var a = mole.name; console.log(a)
總結：直接修改name不會影響mole.name，一定程度保護了命名空間。有兩個缺點，一，外部還是可以修改mole的屬性和方法。二，命名空間有時長起來超乎你的想像。適合一些小型的封裝，如一些配置。
二、立即執行函數 + 閉包(實現模塊的基本方法)
立即函數可以創建作用域，閉包則可以形成私有變數和函數
//創建 var mole = (function(){ var privateName = 'inner'; //私有變數 var privateFunc = function(){ //私有函數 console.log('私有函數') } return {
6. 前端小白想問，jsp後面是什麼意思，怎麼用求大神解答
現在前端用Webpack打包JS和其它文件已經是主流了，加上Node的流行，使得前端的工程方式和後端越來越像。所有的東西都模塊化，最後統一編譯。Webpack因為版本的不斷更新以及各種各樣紛繁復雜的配置選項，在使用中出現一些迷之錯誤常常讓人無所適從。所以了解一下Webpack究竟是怎麼組織編譯模塊的，生成的代碼到底是怎麼執行的，還是很有好處的，否則它就永遠是個黑箱。當然了我是前端小白，最近也是剛開始研究Webpack的原理，在這里做一點記錄。
編譯模塊
編譯兩個字聽起來就很黑科技，加上生成的代碼往往是一大坨不知所雲的東西，所以常常會讓人卻步，但其實裡面的核心原理並沒有什麼難。所謂的Webpack的編譯，其實只是Webpack在分析了你的源代碼後，對其作出一定的修改，然後把所有源代碼統一組織在一個文件里而已。最後生成一個大的bundle JS文件，被瀏覽器或者其它Javascript引擎執行並返回結果。
在這里用一個簡單的案例來說明Webpack打包模塊的原理。例如我們有一個模塊mA.js
var aa = 1; function getDate() { return new Date(); } mole.exports = { aa: aa, getDate: getDate }
我隨便定義了一個變數aa和一個函數getDate，然後export出來，這里是用CommonJS的寫法。
然後再定義一個app.js，作為main文件，仍然是CommonJS風格：
var mA = require('./mA.js'); console.log('mA.aa =' + mA.aa); mA.getDate();
現在我們有了兩個模塊，使用Webpack來打包，入口文件是app.js，依賴於模塊mA.js，Webpack要做幾件事情：
從入口模塊app.js開始，分析所有模塊的依賴關系，把所有用到的模塊都讀取進來。 每一個模塊的源代碼都會被組織在一個立即執行的函數里。 改寫模塊代碼中和require和export相關的語法，以及它們對應的引用變數。 在最後生成的bundle文件里建立一套模塊管理系統，能夠在runtime動態載入用到的模塊。
我們可以看一下上面這個例子，Webpack打包出來的結果。最後的bundle文件總的來說是一個大的立即執行的函數，組織層次比較復雜，大量的命名也比較晦澀，所以我在這里做了一定改寫和修飾，把它整理得盡量簡單易懂。
首先是把所有用到的模塊都羅列出來，以它們的文件名（一般是完整路徑）為ID，建立一張表：
var moles = { './mA.js': generated_mA, './app.js': generated_app }
關鍵是上面的generated_xxx是什麼？它是一個函數，它把每個模塊的源代碼包裹在裡面，使之成為一個局部的作用域，從而不會暴露內部的變數，實際上就把每個模塊都變成一個執行函數。它的定義一般是這樣：
function generated_mole(mole, exports, webpack_require) { // 模塊的具體代碼。 // ... }
在這里模塊的具體代碼是指生成代碼，Webpack稱之為generated code。例如mA，經過改寫得到這樣的結果：
function generated_mA(mole, exports, webpack_require) { var aa = 1; function getDate() { return new Date(); } mole.exports = { aa: aa, getDate: getDate } }
乍一看似乎和源代碼一模一樣。的確，mA沒有require或者import其它模塊，export用的也是傳統的CommonJS風格，所以生成代碼沒有任何改動。不過值得注意的是最後的mole.exports = ...，這里的mole就是外面傳進來的參數mole，這實際上是在告訴我們，運行這個函數，模塊mA的源代碼就會被執行，並且最後需要export的內容就會被保存到外部，到這里就標志著mA載入完成，而那個外部的東西實際上就後面要說的模塊管理系統。
接下來看app.js的生成代碼：
function generated_app(mole, exports, webpack_require) { var mA_imported_mole = webpack_require('./mA.js'); console.log('mA.aa =' + mA_imported_mole['aa']); mA_imported_mole['getDate'](); }
可以看到，app.js的源代碼中關於引入的模塊mA的部分做了修改，因為無論是require/exports，或是ES6風格的import/export，都無法被JavaScript解釋器直接執行，它需要依賴模塊管理系統，把這些抽象的關鍵詞具體化。也就是說，webpack_require就是require的具體實現，它能夠動態地載入模塊mA，並且將結果返回給app。
到這里你腦海里可能已經初步逐漸構建出了一個模塊管理系統的想法，我們來看一下webpack_require的實現：
// 載入完畢的所有模塊。 var installedMoles = {}; function webpack_require(moleId) { // 如果模塊已經載入過了，直接從Cache中讀取。 if (installedMoles[moleId]) { return installedMoles[moleId].exports; } // 創建新模塊並添加到installedMoles。 var mole = installedMoles[moleId] = { id: moleId, exports: {} }; // 載入模塊，即運行模塊的生成代碼， moles[moleId].call( mole.exports, mole, mole.exports, webpack_require); return mole.exports; }
注意倒數第二句里的moles就是我們之前定義過的所有模塊的generated code：
var moles = { './mA.js': generated_mA, './app.js': generated_app }
webpack_require的邏輯寫得很清楚，首先檢查模塊是否已經載入，如果是則直接從Cache中返回模塊的exports結果。如果是全新的模塊，那麼就建立相應的數據結構mole，並且運行這個模塊的generated code，這個函數傳入的正是我們建立的mole對象，以及它的exports域，這實際上就是CommonJS里exports和mole的由來。當運行完這個函數，模塊就被載入完成了，需要export的結果保存到了mole對象中。
所以我們看到所謂的模塊管理系統，原理其實非常簡單，只要耐心將它們抽絲剝繭理清楚了，根本沒有什麼深奧的東西，就是由這三個部分組成：
// 所有模塊的生成代碼 var moles； // 所有已經載入的模塊，作為緩存表 var installedMoles； // 載入模塊的函數 function webpack_require(moleId);
當然以上一切代碼，在整個編譯後的bundle文件中，都被包在一個大的立即執行的匿名函數中，最後返回的就是這么一句話：
return webpack_require(『./app.js');
即載入入口模塊app.js，後面所有的依賴都會動態地、遞歸地在runtime載入。當然Webpack真正生成的代碼略有不同，它在結構上大致是這樣：
(function(moles) { var installedMoles = {}; function webpack_require(moleId) { // ... } return webpack_require('./app.js'); }) ({ './mA.js': generated_mA, './app.js': generated_app });
可以看到它是直接把moles作為立即執行函數的參數傳進去的而不是另外定義的，當然這和上面的寫法沒什麼本質不同，我做這樣的改寫是為了解釋起來更清楚。
ES6的import和export
以上的例子里都是用傳統的CommonJS的寫法，現在更通用的ES6風格是用import和export關鍵詞，在使用上也略有一些不同。不過對於Webpack或者其它模塊管理系統而言，這些新特性應該只被視為語法糖，它們本質上還是和require/exports一樣的，例如export：
export aa // 等價於: mole.exports['aa'] = aa export default bb // 等價於: mole.exports['default'] = bb
而對於import：
import {aa} from './mA.js' // 等價於 var aa = require('./mA.js')['aa']
比較特殊的是這樣的：
import m from './m.js'
情況會稍微復雜一點，它需要載入模塊m的default export，而模塊m可能並非是由ES6的export來寫的，也可能根本沒有export default，所以Webpack在為模塊生成generated code的時候，會判斷它是不是ES6風格的export，例如我們定義模塊mB.js:
let x = 3; let printX = () => { console.log('x = ' + x); } export {printX} export default x
它使用了ES6的export，那麼Webpack在mB的generated code就會加上一句話：
function generated_mB(mole, exports, webpack_require) { Object.defineProperty(mole.exports, '__esMole', {value: true}); // mB的具體代碼 // .... }
也就是說，它給mB的export標注了一個__esMole，說明它是ES6風格的export。這樣在其它模塊中，當一個依賴模塊以類似import m from './m.js'這樣的方式載入時，會首先判斷得到的是不是一個ES6 export出來的模塊。如果是，則返回它的default，如果不是，則返回整個export對象。例如上面的mA是傳統CommonJS的，mB是ES6風格的：
// mA is CommonJS mole import mA from './mA.js' console.log(mA); // mB is ES6 mole import mB from './mB.js' console.log(mB);
我們定義get_export_default函數：
function get_export_default(mole) { return mole && mole.__esMole? mole['default'] : mole; }
這樣generated code運行後在mA和mB上會得到不同的結果：
var mA_imported_mole = webpack_require('./mA.js'); // 列印完整的 mA_imported_mole console.log(get_export_default(mA_imported_mole)); var mB_imported_mole = webpack_require('./mB.js'); // 列印 mB_imported_mole['default'] console.log(get_export_default(mB_imported_mole));
這就是在ES6的import上，Webpack需要做一些特殊處理的地方。不過總體而言，ES6的import/export在本質上和CommonJS沒有區別，而且Webpack最後生成的generated code也還是基於CommonJS的mole/exports這一套機制來實現模塊的載入的。
模塊管理系統
以上就是Webpack如何打包組織模塊，實現runtime模塊載入的解讀，其實它的原理並不難，核心的思想就是建立模塊的管理系統，而這樣的做法也是具有普遍性的，如果你讀過Node.js的Mole部分的源代碼，就會發現其實用的是類似的方法。這里有一篇文章可以參考。
以上就是本文的全部內容，希望對大家的學習有所幫助，也希望大家多多支持腳本之家。
您可能感興趣的文章:探索webpack模塊及webpack3新特性關於webpack2和模塊打包的新手指南（小結）詳解react-webpack2-熱模塊替換[HMR]webpack配置sass模塊的載入的方法詳解用webpack把我們的業務模塊分開打包的方法Webpack常見靜態資源處理-模塊載入器（Loaders）+ExtractTextPlugin插件詳解webpack非同步載入業務模塊jQuery 移動端拖拽（模塊化開發，觸摸事件，webpack）
7. 前端項目中下載好依賴後會出現什麼文件夾
前端項目中下載好依賴後會出現cmd進入前端vue項目的根目錄。npm項目依賴組件安裝：cmd進入前端vue項目的根目錄，輸入命令cnpminstall，會根據前端項目的依賴關系下載好相關的組件，存在項目目錄的node_moles文件夾下。
8. 前端項目的開發流程
前端開發流程概述
前端開發流程可分為需求分析、開發階段、測試階段、維護階段，下面分別進行敘述。
2.1 需求分析
這個環節中，首先是和客戶進行交流，了解客戶的需求，然後分析項目的可行性，撰寫項目需求文檔。如果項目可行，則起討論具體方案，分模塊分步驟進行規劃，分析項目進度安排、所需成本，進行原型設計（包括頁面布局圖，頁面邏輯流程圖，說明文檔等。通過原型設計，可以讓項目組和客戶都可以對項目有一個直觀感受，同時可以低成本高效率的復現業務場景和各模塊流程）。
可以說需求分析階段是整個前端項目的基礎，基礎不牢，地動山搖。可以試想，如果和客戶溝通不順暢，有的方面客戶沒搞清楚是什麼效果，開發完成後就可能與客戶發生糾紛；如果可行性有問題，有的模塊很難實現或成本超出預算，就很難處理。
2.2 開發階段
這個環節是前端工程師主要參與的部分，按照需求分析階段的規劃按步驟完成任務。
根據產品需求分析文檔和原型圖進行UI設計，對產品的整體美術風格、交互設計、界面結構、操作流程等做出設計。負責項目中各種交互界面、圖標、LOGO、按鈕等相關元素的設計與製作。
根據UI設計進行規劃，提取界面中可以復用的模塊方便重復利用，分析界面是否有實現難度比較困難的地方，進行溝通和功能排期，按功能大小以及難度進行功能時間的評估，和後端溝通好排期時間，保證大家能夠更有效地開發合作，針對功能復雜的地方要先理清思路。
不要盲目開發前端搭建框架。根據設計圖進行前端界面開發，以及遇到的問題及時與產品、UI、後台人員溝通，保持大家信息一致，針對不清楚的地方也要及時溝通，以免做錯功能。
根據後端介面進行欄位填充，以及部分功能開發。針對缺少的欄位或者數據結構進行提出，及時與後端反應，盡量讓大家都能以最小的改動完成後續開發工作。前後端都要按照規范進行開發，針對不規范的地方要給與提出、指正，營造出規范的工作模式，以後維護成本和溝通成本更低以及開發效率更高。如果前端的設計進度遠遠超前後端的介面和數據結構設計，也不必等後端，可以自行開發nodejs伺服器配合postman等介面軟體進行開發。
前後端功能聯調、完成自測。檢查功能完成情況，看是否有遺漏，出現問題及時溝通解決。
2.3 測試階段
發布測試、修改bug、發布上線，自測完成後提交測試，測試根據提交的項目以及需求進行測試，提出bug給相關人員修改，開發人員周期性的配合修改bug，保證今天能夠修復昨天的bug。
發布dev環境，配合測試，修復bug以及需求優化
發布test環境，修復bug以及需求優化
發布it環境，修復bug以及需求優化
發布pre環境，修復bug以及需求優化
pre驗收之後，發布線上環境，產品進行驗收
2.4 維護階段
如果客戶驗收通過，項目就進入了維護階段，程序的維護包括程序上線後後續bug的修復和程序版本的更新。
3 個人經驗總結
3.1 文檔很重要
前端項目的文檔似乎已經作為前端工程化的標准流程之一了，文檔寫的好，可以便於同事快速了解你的代碼功能和需求，便於協作。可以想像，隨之項目復雜度增加，體量越來越龐大，開發團隊人數也越來越多。這種情況下，如果像變魔術一樣隱匿中間流程而直接得出結果，後果可想而知：項目復雜度越增加就越難以管理，開發效率低，合作混亂，結果甚至導致項目死亡。
好的文檔看起來就像一個產品說明書，但作用卻遠遠超過了說明書，不僅僅告訴你如何使用，還應該告訴你項目的設計思路，用了哪些組件，哪些部分不完善，將來有什麼規劃等等。這是一份比較好的說明文檔。
3.2 與客戶及時溝通很重要
3.3 扎實的基本功很重要
盡管當下框架、函數庫、工具包等更新迭代非常快，前端工程師有很多新的知識要學，但原生JS、HTML和CSS依然是重要的基本功，在學習前沿工具的同時不能放棄基本功的訓練。