webpack 和vscode的区别_webpack vscode - CSDN
精华内容
参与话题
  • VsCode下部署Webpack4.x版本环境

    千次阅读 2019-06-19 19:22:57
    2.在VSCODE中 打开这个文件夹 3.在这个文件夹目录下打开终端 4.执行 npm init 会提示让你输入一些信息。默认就一直回车。 结束后,生成一个packge.json文件 5.新建dist文件夹(浏览器最终要读取的...

    1.桌面新建一个文件夹,我取名Test2

    2.在VSCODE中 打开这个文件夹

    3.在这个文件夹目录下打开终端

    4.执行

    npm init

    会提示让你输入一些信息。默认就一直回车。

    结束后,生成一个packge.json文件

    5.新建dist文件夹(浏览器最终要读取的文件都输出在这里面),src文件夹(用于创建一个项目入口,自己项目都写在这里)

    同时在dist中创建一个index.html ,在src中创建一个index.js

    6.开始安装webpack(局部安装:只用于该项目)

    --save-dev 表示保存在项目里,并写入package.json配置文件。

    npm install webpack --save-dev

    安装成功后如图(细心点会发现左边同时生成了node_modules这个文件夹。就是来管理各种依赖的。

    在webpack4 已经将 webpack 命令行相关的内容都迁移到 webpack-cli,即除了webpack 外,我们还需要安装 webpack-cli(局部安装):

    这两者都需要装在同一个目录下,所以我都选择局部安装。你也可以全部全局安装。

    npm install webpack-cli --save-dev

    7.继续安装lodash(

    Lodash是一个著名的javascript原生库,不需要引入其他第三方依赖。是一个意在提高开发者效率,提高JS原生方法性能的JS库。简单的说就是,很多方法lodash已经帮你写好了,直接调用就行,不用自己费尽心思去写了,而且可以统一方法的一致性。Lodash使用了一个简单的 _ 符号,就像Jquery的 $ 一样,十分简洁。)  这个并不是一定要装,是因为后面官网的例子有用到所以这里需要安装一下。

    npm install  lodash --save-dev

    8. 编写例子 根据官网上的来编写src/index.js,dist/index.html

    index.js

    import _ from 'lodash';
    function component() {
    var element = document.createElement('div');
    // Lodash, now imported by this script
    element.innerHTML = _.join(['Hello', 'webpack'], ' ');
    
    return element;
     }
    document.body.appendChild(component());
    

    index.html

    <!doctype html>
      <html>
       <head>
         <title>Getting Started</title>
       </head>
       <body>
        <script src="main.js"></script>
       </body>
      </html>
    

    9.打包项目

    npx webpack

    成功后dist目录下生成了main.js文件

    10.这时候右键选择index.html文件在浏览器打开,就能看到显示效果了。

    如果没有这个工具,先去VSCODE中下载一下这个工具就行了。

    11.警告

    这个警告是打包这个项目时你需要选择是production(生产环境)还是development(开发环境),后面我们解决。

    模块

    12.上述我们是自己输入命令来一个个配置,这里我们需要采用更好的方法,通过配置文件去配置。删除main.js,

    在新项目下新建一个webpack.config.js文件,写入

    const path = require('path');
    module.exports = {
    entry: './src/index.js',//代表入口文件
    output: {
    filename: 'bundle.js',//代表输出文件
    path: path.resolve(__dirname, 'dist')//输出位置
     }
    };

    13.现在,让我们再次运行构建,而且是通过使用我们的新配置文件

    npx webpack --config webpack.config.js

    此时dist文档下出现一个bundle.js的文件,修改dist/index.html 改成引入bundle.js

    <script src="bundle.js"></script>

    浏览器中打开index.html,仍可以出现文本:'Hello webpack'。

    实际上bundle.js跟我们刚才通过命令npx webpack生成的main.js内容是一样的。但是通过配置文件,我们可以添加更多配置。

    14.上述命令我们可以设置一个小捷径,在package.json里面添加npm脚本就能实现:

    注意到这里还同时添加了构建项目时需要选择的环境

    --mode development

    现在我们只需要在项目终端下,执行

    npm run build

    就能重新构建这个项目了

    可以看到项目构建完成了,同时警告也不见了。

    15.  webpack热更新

    所谓热更新,就是在浏览器能同步刷新你的代码。webpack 热更新依赖 webpack-dev-server

    1.局部安装依赖:

    npm install webpack-dev-server --save-dev

    2.在 webpack.config.js 配置相关参数

    module.exports = {
      //...
      devServer: {
        contentBase: path.join(__dirname, 'dist'),
        host:'localhost',//服务器IP地址,可以使用IP也可以使用localhost
        compress: true,//服务端压缩是否打开
        port: 9000//配置服务端端口号
      }
    };

    3.在package.json里配置webpack-dev-server

    4.启动服务器,在终端输入

    npm run server

    服务器启动成功,在浏览器输入localhost:9000即可访问到同一页面。

    右键直接打开index.html的地址:

    通过服务器访问的地址:

    16.热更新效果展示

    附加:

    webpack坑系列--安装webpack-cli

    npm全局安装和局部文件安装区别

    为什么要用npx

     

     

     

     

     

     

     

     

     

    展开全文
  • 其中一个比较好的插件就是path autocomplete,但是这里有个问题,当通过webpack的alias引用的时候,path autocomplete是不起作用的 import sss from "@common/" 然后后面也没有路径提示,自己手动写好他妈的烦 ...

    vscode确实是比较好的编辑器
    其中一个比较好的插件就是path autocomplete,但是这里有个问题,当通过webpack的alias引用的时候,path autocomplete是不起作用的

    import sss from "@common/"
    

    然后后面也没有路径提示,自己手动写好他妈的烦
    后来查了下,需要在项目跟路径下配置一个jsconfig.json,让vscode能够识别出alias
    废话不多说,
    webpack配置

    resolve: {
            alias: {
              "@actions": `${this.srcPathAbsolute}/actions/`,
              "@components": `${this.srcPathAbsolute}/components/`,
              "@commonComp": `${this.srcPathAbsolute}/components/common/`,
              "@common": `${this.srcPathAbsolute}/common/`
        }
    }
    

    jsconfig.json的配置

    {
      "compilerOptions": {
        "target": "es2017",
        "allowSyntheticDefaultImports": false,
        "baseUrl": "./",
        "paths": {
          "@actions/*": ["src/actions/*"],
          "@components/*": ["src/components/"],
          "@commonComp/*": ["src/components/common/"],
          "@common/*": ["src/common/*"],
          "@reducers/*": ["src/reducers/*"],
          "@images/*": ["src/images/*"],
          "@lib/*": ["src/lib/*"],
          "@assets/*": ["src/assets/*"],
          "@util/*": ["src/utility/*"],
          "config/*": ["src/config/*"],
          "sources/*": ["src/sources/*"],
          "stores/*": ["src/stores/*"],
          "styles/*": ["src/styles/*"]
        }
      },
      "exclude": ["node_modules", "dist"],
      "include": ["src"]
    }
    

    这样在你引入路径的时候,如果使用webpack的alias的时候,就可以自动提示路径了

    展开全文
  • 最近很长一段时间,VSCode 似乎成为了前端口中的标准开发编辑器,前端圈到处都在推荐 VSCode,劝说其他人放弃 Sublime, WebStorm, Atom 之流,仿佛真的是信巨硬,得永生一般。而吾辈作为一个长时间使用 JetBrains 系...

    前言

    不能认清自己,怎能看清别人?

    最近很长一段时间,VSCode 似乎成为了前端口中的标准开发编辑器,前端圈到处都在推荐 VSCode,劝说其他人放弃 Sublime, WebStorm, Atom 之流,仿佛真的是信巨硬,得永生一般。而吾辈作为一个长时间使用 JetBrains 系 IDE 的全沾开发者,这里就来对比一下 WebStorm 与后起之秀 VSCode 之前的异同点吧

    比较

    插件生态

    VSCode 的生态无疑非常好,基于 Web 技术构建的编辑器同样可以使用 Web 技术开发插件,而 Web 开发人员的数量也确实非常庞大。且由于其轻量跨平台的特性,受到很多开发者的喜爱,将之作为主力文件编辑器或者将其打造成 IDE 使用。它们的插件市场首页分别如下

    VSCode
    VSCode 插件市场

    WebStorm
    WebStorm 插件市场

    WebStorm 官方给出的插件总数是 1607,而 VSCode 吾辈并未找到插件的总数量,但显而易见,VSCode 的插件数量应该远远高于这个数字。而且你可以看到 WebStorm 下载量第一的插件仅仅只下载过 5,558,762 次,而 VSCode 的热门插件的下载数量是以 M 来计算的。我们来搜索一下前端流行打包工具 webpack,对比一下结果。

    VSCode
    webpack for vscode

    WebStorm
    webpack for WebStorm

    是的,VSCode 搜索到了 16 个插件,而 WebStorm 的搜索结果是。。。0?不了解 WebStorm 的小伙伴可能会有疑问,难道 WebStorm 不支持 webpack 嘛?那要它何用,还是拉出去砍了吧!
    泥萌先别急着掀桌子,个中缘由且听吾辈细细说来。之所以出现这种情况,主要是因为二者的策略不同造成的。WebStorm 的目标是让用户拥有开箱即用的生产力工具,下载安装完成后就可以立即进行项目开发了,所以它将很多功能内置了 IDE 之中,或者是由官方开发插件出来,然后直接集成到 IDE 中,给个人开发者开发插件的机会不多。
    而 VSCode 由于官方的开发团队没那么强大,而且又是免费的开源产品,所以理所当然只能发动广大人民群众的力量了,所以有很多插件就只能交给第三方开发者进行开发和维护。而这点也造成了安装完 VSCode 之后并不能立即使用,还需要下载插件、进行配置等一系列操作。
    以上两种模式的孰优孰劣早有人分析过,这里吾辈只说自己的使用体验。WebStorm 的开箱即用做的确实比 VSCode 更好,但问题在于如果官方不支持的话就会很难受,因为其实并没有太多人同时精通前端和 Java(是的,必须使用 Java 开发插件)。这也是吾辈目前仍然使用 VSCode 作为主力文本编辑器编辑配置文件,以及使用它写 Markdown 文章的原因,包括这篇文章亦是通过 VSCode 写出来的。
    Markdown 写作截图

    附: 插件开放让第三方实现与官方自己实现并集成的优劣之分参考知乎的一篇文章: Visual Studio Code 有哪些工程方面的亮点
    通过插件来扩展功能的做法已经是司空见惯了,但如何保证插件和原生功能一样优秀呢?历史告诉我们:不能保证。大家可以参考 Eclipse,插件模型可以说是做得非常彻底了,功能层面也是无所不能,但存在几个烦人的问题:不稳定、难用、慢,所以不少用户转投 IntelliJ 的怀抱。可谓成也插件,败也插件。问题的本质在于信息不对称,它导致不同团队写出来的代码,无论是思路还是质量,都不一致。最终,用户得到了一个又乱又卡的产品。所以要让插件在稳定性、速度和体验的层面都做到和原生功能统一,只能是一个美好的愿望。
    来看看其他 IDE 是怎么做的,Visual Studio 自己搞定所有功能,并且做到优秀,让别人无事可做,这也成就了其 “宇宙第一 IDE” 的美名;IntelliJ 与之相仿,开箱即用,插件可有可无。这么看起来,自己搞定所有的事情是个好办法,但大家是否知道,Visual Studio 背后有上千人的工程团队,显然,这不是 VS Code 这二十几号人能搞定的。他们选择了让大家来做插件,那怎么解决 Eclipse 所遇到的问题呢?
    这里分享一个小知识 ——Eclipse 核心部分的开发者就是早期的 VS Code 团队。嗯,所以他们没有两次踏入同一条河流。与 Eclipse 不同,VS Code 选择了把插件关进盒子里。
    这样做首先解决的问题就是稳定性,这个问题对于 VS Code 来说尤为重要。都知道 VS Code 基于 Electron,实质上是个 node.js 环境,单线程,任何代码崩了都是灾难性后果。所以 VS Code 干脆不信任任何人,把插件们放到单独的进程里,任你折腾,主程序妥妥的。
    VS Code 团队的这一决策不是没有原因的,正如前面提到的,团队里很多人其实是 Eclipse 的旧部,自然对 Eclipse 的插件模型有深入的思考。Eclipse 的设计目标之一就是把组件化推向极致,所以很多核心功能都是用插件的形式来实现的。遗憾的是,Eclipse 的插件运行在主进程中,任何插件性能不佳或者不稳定,都直接影响到 Eclipse,最终结果是大家抱怨 Eclipse 臃肿、慢、不稳定。VS Code 基于进程做到了物理级别的隔离,成功解决了该问题。实际上进程级别的隔离也带出了另一个话题,那就是界面与业务逻辑的隔离。

    智能提示

    作为写代码的工具,代码提示已经司空见惯了。但是,就算同样是代码提示,有的代码提示只是简单的代码片段(snippets),而有的却是基于代码语法树分析进行的,甚至于编辑器会学习使用者的习惯,将最常用的提示放在最前面。WebStorm 从始至终一直都是第三种,而 VSCode 最近官方才开发了基于 AI 自动学习的智能提示插件 Visual Studio IntelliCode

    VSCode
    VSCode 智能提示

    WebStorm
    WebStorm 智能提示

    自动修复

    我们在日常开发中经常会遇到一些低级问题,而编辑器其实是有可能帮我们自动修复的。这里便对吾辈了解的一些问题进行对比,问题详细信息请参考文章 JavaScript 规范整理

    注: VSCode 没有原生的自动修复功能,必须使用插件才行。
    分类 对比项 VSCode WebStorm
    命名规范
    不要使用拼音命名 支持 支持
    函数中的变量 支持 支持
    内部变量 不支持 不支持
    不要使用无意义的前缀命名 支持 支持
    ES6
    优先使用 const/let 支持 支持
    使用新的函数声明方式 支持 支持
    优先使用箭头函数而非 function 不支持 支持
    不要使用 if 判断再赋予默认值 不支持 不支持
    优先使用 Map 做键值对映射而非传统的对象 不支持 不支持
    优先使用模板字符串拼接多个字符串变量 不支持 支持
    当独立参数超过 3 个时使用对象参数并解构 不支持 支持
    不要写多余的 await 支持 支持
    不要使用 == 进行比较 支持 支持
    使用计算属性名替代使用方括号表示法赋值 不支持 不支持
    逻辑代码
    不要判断一个 Boolean 值并以此返回 Boolean 值 支持 支持
    不要使用多余的变量 支持 支持
    不要使用嵌套 if 不支持 支持
    不要先声明空对象然后一个个追加属性 不支持 不支持
    不要使用无意义的函数包裹 不支持 不支持
    不要使用三元运算符进行复杂的计算 不支持 支持
    如果变量有所关联则使用对象而非多个单独的变量 不支持 不支持
    应该尽量解决编辑器警告 不支持 不支持
    使用类型定义参数对象 不支持 不支持
    尽量扁平化代码 支持 支持
    自执行函数前面必须加分号 不支持 不支持

    下面是一张 WebStorm 官方使用自动修复的动图
    WebStorm 自动修复

    重构

    说起重构的话,VSCode 可以简单的说是做的太,而 WebStorm 则是相反做的太,下面继续以表格的形式进行对比。

    WebStorm 较新版本已经修复了 2018.02 重命名会自动索引字符串的问题(变成可选项了)。
    分类 操作 VSCode WebStorm
    重命名
    变量重名名 支持 支持
    复杂变量重命名 不支持 支持
    全局重命名 支持 支持
    正则重命名 存在 bug 支持
    文件重命名 不支持 支持
    提取
    提取表达式为变量 支持 支持
    提取代码段为函数 支持 支持
    提取函数到新文件 支持 支持

    WebStorm 重命名文件
    WebStorm 重命名文件

    Git/GitHub 集成

    VSCode 的 Git 支持一直不太行,就算加了插件 GitLens 也无法比得上 WebStorm。

    分类 操作 VSCode WebStorm
    Git
    commit 提交 难用 支持
    push 推送 支持 支持
    pull 拉取 支持 支持
    merge 合并 支持 支持
    历史记录 难用 支持
    reset 回退 支持 支持
    revert 回退 难用 支持
    stash 暂存 支持 支持
    branch 分支操作 支持 支持
    GitHub
    分享到 GitHub 不支持 支持
    从 GitHub 选择拉取 不支持 支持
    分享到 Gist 支持 支持

    放两张图对比一下

    VSCode GitLens
    GitLens

    WebStorm
    WebStorm Git

    前端支持

    前面提过,VSCode 生态很好,基本上很多语言/框架都有支持,而且官方也有一些非常优秀的插件。但是,有一些地方很重要,VSCode 对于 HTML/CSS/JavaScript 这些 Web 基本元素的支持相比于 WebStorm 确实可以说的上是糟糕。

    先来测试前端三剑客: HTML/CSS/JavaScript

    VSCode
    VSCode

    WebStorm
    WebStorm

    可以看到,对于 HTML/CSS 之间的代码提示、跳转这些基本功能,VSCode 其实并没有做好。现代前端说是不再写 HTML 了,但实际上终究还是要写(即便是 JSX 还是要符合写 HTML 的直觉的),VSCode 代码提示在这里明显不太够看。还有一点也很有趣,VSCode 在打完 document.querySelector('#hello') 之后彻底没了动静,而 WebStorm 在 style 输入完成之后,立刻就有了各种 CSS 属性提示了。

    附: VSCode 中通过输入 h1.hello#hello Tab 之后就得到代码是一种前端 HTML 代码编写方式,被称为 Zen Coding。但实际上,这种编写方式在代码提示方面存在劣势,所以使用 WebStorm 时并未演示。
    附: VSCode 引用文件路径提示需要插件 Path Intellisense

    对于库的开发者而言最难受的地方是 VSCode 实质上依赖于 TypeScript 才能做到代码提示,如果你也像吾辈是一位 JavaScript SDK 的开发者,那么也会遇到这件令人郁闷的事情: 如果想要使用你的 JavaScript SDK 的 VSCode 用户有正常的代码提示的话,你就必须接触 TypeScript。要么使用 TypeScript 重构整个 SDK,要么写 .d.ts 专门为 VSCode 维护一份注释文档,详情可以参考文章 JavaScript => TypeScript 迁移体验

    历史记录

    不知你是否曾遇到过,正在编辑着一个文件,突然断电,或者是因为其他什么原因,导致文件内容被清空了。或者是误删了代码之后之前的代码还没提交,又不能撤回那么多次,导致代码重写的经历呢?吾辈就曾经经历过,所以对本地历史记录这个功能相当重视,然而很遗憾,VSCode 依旧需要第三方插件 Local History 才能支持。

    VSCode Local History
    VSCode Local History

    WebStorm
    WebStorm

    两者相比主要有以下不同

    对比项 VSCode WebStorm
    原始文件是否为人类可读 否(XML 不列入人类可读格式中)
    是否可以添加标签
    是否可以对比
    是否可以合并

    主题配色

    两者都支持黑暗主题,而且都是默认设置,也同样支持使用插件定制界面。下面是两者的截图

    VSCode
    VSCode 主界面

    WebStorm
    WebStorm 主界面

    事实上,上面两者都使用了主题。VSCode 是 Monokai,WebStorm 是 Material。但其实 WebStorm 的 Material 主题 还是存在一些 Bug 的,例如有些地方图标莫名的错位之类,VSCode 目前吾辈还未曾遇到过这类问题。

    使用性能

    WebStorm 确实很吃内存,尤其是项目刚刚打开的时候,索引会疯狂地吃 CPU/内存/硬盘,如果电脑性能不行的话这个过程所需时间可能泡面都够了。但基于 Chrome 内核的 VSCode 在使用各种插件打造成前端 IDE 之后吃的内存也并不少。吾辈打开了项目 rx-util,可以看到 VSCode 每个插件确实都放在了单独的进程里(Chrome 系的习惯 #笑),相比之下 WebStorm 只有两个进程,其中一个还是启动的 nodejs,整体对比下来其实相差不大。

    任务管理器

    东家

    VSCode 背后站着微软,俗成 M&dollar;,开发了宇宙最强 IDE Visual Studio。而 WebStorm 则是基于 JetBrains 平台专门为前端进行特殊处理优化的 IDE,背后则是业界最智能的 IDE 的开发公司 JetBrains(捷克公司)。两者在 IDE/编辑的开发上都相当有经验,然而,有一点本质的不同:IDE 对于 JetBrains 而言几乎是全部,而 VSCode 对于 M&dollar; 则只是开发的一部分 -- 编辑器。

    VSCode => VSCode Remote => GitHub => GitHub Actions => Azure,从 M&dollar; 的一系列变化来看,这对开发者是真的相当上心,从本地开发、远程协作、版本控制、自动化流程控制 CI/CD 到部署到云端,完全是一站式的体验。相比于国内的云服务商,MS 显然更加开放、更加为开发者着想。
    而 JetBrains,虽然现在也有了编程语言 Kotlin、项目管理工具 Space(包含 CI/CD 工具 TeamCity),但本质上在其领域内,除了 IDE,其他的东西都没能形成特别大的优势(Kotlin 只能用于开发 Android 平台,而 Web 技术甚至能开发全端;TeamCity 虽然很漂亮,但似乎人们更喜欢开源的 Jenkins)。
    未来 VSCode 一统天下似乎是必然之势,但目前而言,其尚且年幼,唯有 WebStorm 正值壮年。

    附:例如某只企鹅,开发的大多数云服务都是私有服务,使用上比开源的还难用而且还强制绑定到自家云服务上,使人不得不用全家桶(问题是体验又烂,文档死难找)
    附: 居然连 “文档和 Demo 有可能过期,但代码一定是最新的” 这种话都能说出来,与 MS 花大力气创造开源的 VSCode 简直是天壤之别。
    附: 没有对比就没有伤害!

    总结

    其实在 Atom/VSCode 出现之前,WebStorm 因为在这个领域没有对手而发展缓慢,它们的出现使得 WebStorm 有了压力,良性竞争,这当然是好事。即便如此,就目前而言,VSCode 作为一个 IDE 来讲仍然比不上 JetBrains 全家桶系列。
    说了上面这么多,总的来说: 如果你需要一个文本编辑器,那么推荐你用 VSCode,因为它既漂亮又生态丰富,想写点什么很方便。但是,如果你需要真正开发项目,则 WebStorm 更加合适,完全开箱即用的体验,不需要安装/配置任何插件就能立刻开始项目,强大的编辑器可以让你写代码更舒服一点。(其实是没钱就用免费的 VSCode,有钱就上 WebStorm 啦!)

    展开全文
  • 使用VsCode进行webpack打包

    万次阅读 2018-07-12 17:29:25
    前言:折腾了两天,折腾的有点伤心,以往的项目是站在大树地下...第一步:确保安装node.js,我的版本是v6.11.1webpack版本4.16第二步:1:在电脑本机建立一个新文件夹.2:打开vscode选择 文件&gt;&gt;打开文件夹....

    前言:折腾了两天,折腾的有点伤心,以往的项目是站在大树地下使用框架自带的打包框架,当自己用webpack来实现自动打包的时候却发现,各种红~~~当自己把环境搭建好写出第一个demo的时候就发现这些过程都是很经验的积累吧.


    第一步:

    确保安装node.js,我的版本是v6.11.1

    webpack版本4.16


    第二步:

    1:在电脑本机建立一个新文件夹.

    2:打开vscode选择 文件>>打开文件夹.

    3:CTRL+shift+y 选择终端输入npm init 然后执行.

    4: 初始化后的文件夹,里面只有一个json文件.

    5: 接下来装webpack ,命令 npm install webpack --save-dev

    然后你就会发现多了 node_modules 这个文件(大家注意这个文件目录,这是个坑)


    6:在这个文件下创建一个demo.js文件,并创建一个函数.

    function hello() {
    alert("老哥,了解下");
    }
    hello();

    7:然后输入命令  webpack demo.js -o demo.bundle.js

    其中 demo.dundle.js是打包后生成的文件的文件名(名字你随意...).

    8:由于我用的webpack版本是最新版4.16,新版webpack4的语法更加严格,网上很多的教程都是很早的版本,基本都是炮灰.跑偏了,新版讲究个有开发模式和生产模式两种.我们找到开始 npm init 创建的package.json

    "scripts": {
        "test": "echo \"Error: no test specified\" && exit 1",
        "dev": "webpack --mode deveplopment",
        "build": "webpack --mode production"

      },

    然后把红色的两个属性添加上(dev:开发模式,build:生产模式)

    区别:一个没压缩,一个压缩了.作用是啥:体积小和代码混淆

    9:打包发现缺少webpack-cli就使用npm install --save-dev webpack-cli -g 全局安装.

    10:然后继续打包发现还是出错:

    原因是,你输入命令 npm run dev或者npm run build 的时候,会默认打包src文件夹下的index.js文件,打包完成后是main.js文件(放在dist),你有没有发现我们一开始安装webpack的时候并没有这个文件生成,所以更别提什么index.js文件了,所以这些我们需要手动创建我们先创建src文件.还有一个dist文件,存放默认的打包生成的文件, 然后在src里再创建index.js文件.

    11:创建好文件后我们再来一波如果打包还有黄色的警告请使用

     npx webpack ./demo.js -o demo.bundle.js --mode development

    上面这个命令.

    打包后的代码


    这样,我们简单的配置就已经完成了!


    在浏览器上执行一次吧

    12:如果想一边写,代码自动打包 使用这个命令 npx webpack --mode development --watch

    注意: 这个命令只是单纯监听了默认的打包路径,也就是能监听到src下index.js的变化,也能够随将变化时进行保存刷新后其自动打包,但是,并不能监听到demo.js.  还有就是你的执行这个命令的时候,它必需属于一直监听的状态, 如果被停止了,那监听状态也停止.


    如果还有不清楚的,就给我留言吧,我看到就回复~~~


    展开全文
  •   既然Electron基于Chromium Node.js,那么我们还是稍微了解一下什么是Node应用,如何创建Node应用   1.1 Node.js 应用是由哪几部分组成的:   在我理解上Node.js应用就是驻扎在Server端的App,它主要由三...
  • webpackVSCode 创建项目的 5步操作

    千次阅读 2018-10-27 16:07:17
    第一步:用 npm 包的管理工具管理起来 指令:npm init -y 结果:会在项目的根目录多出一个 package.json 配置文件 第二步:创建项目的基本结构 ...第三步:借助 webpack-dev-server ...指令:cnpm i webpack-d...
  • vscode中调试webpack构建的项目

    千次阅读 2019-01-02 12:19:34
    webpack的配置中: devtool: 'source-map', launch.json中配置 { &quot;version&quot;: &quot;0.2.0&quot;, &quot;configurations&quot;: [ { &quot;type&quot;: &quot...
  • WebPack整合LayUI详细总结(VSCode)

    千次阅读 2019-10-22 15:41:33
    VSCode构建普通项目 什么是WebPack VSCode整合WebPack打包工具流程 WebPack引入LayUI bug处理
  • 之前学习webpack的安装,然后发现webpack命令在vscode怎么都无法识别,一开始我以为是全局变量不起作用,后来反复核查发现能在cmd中运行 在vscode就是不行。 感谢雨雪风情是你的这篇文章让我解决了问题 解决办法: ...
  • webpack项目中,我们经常会设置alias来引入文件,避免文件路径写的过长过深,但是使用alias的时候会发现路径函数的智能提示不见了,如果路径名称很复杂的话很容易写错而且也不方便。 在vue 项目中,我们经常这样...
  • 在cmd中命令运行都是正常的,但是在vscode中就报错了,一脸懵,错误如下 解决方案 经过了多方百度查找,最终终于解决了 输入命令Set-ExecutionPolicy -Scope CurrentUser 然后再输入RemoteSigned 成功解决 ...
  • 使用 PathIntellisense 还是使用jsconfig.json? 使用 PathIntellisense 只能提示模块路径,并无法让 vs code 的 Intellisense 知道这个模块的信息。 进过一番查找使用jsconfig.json配置可以很好的解决这个问题,只...
  • 文章目录问题描述解决办法vscode debugger 调试 问题描述 在写webpack配置文件的时候,想了解一些变量的详情,因此,需要debugger调试nodejs 解决办法 Nodejs 使用 Chrome DevTools 调试 --inspect-brk "debugger": ...
  • { “compilerOptions”: { “baseUrl”: “./”, “paths”: { “@/": ["src/”] } }, “exclude”: [“node_modules”, “dist”] }
  • launch.json { // 使用 IntelliSense 了解相关属性。 // 悬停以查看现有属性的描述。 // 欲了解更多信息,请访问: ... "version": "0.2.0", "configurations": [ { "type": "node", ...
  • 安装vscode,安装vscode常用插件 下载项目代码 打开Client目录,运行node_module.bat,安装依赖环境 运行项目 第一部分:安装vscode 简介   vscode全称Visual Studio Code是个跨平台的轻量级的代码编辑器 可...
  • 问题:在VSCode下运行webpack命令无效 这个问题搞了我几个小时,找了很多博客,全局安装webpack和webpack-cli npm i webpack webpack-cli -g没有用;把node_global加入到环境变量没有用;在package.json中的script...
  • webpack-dev-server自动打开浏览器时,老是打开搜狗浏览器,修改电脑默认浏览器也无效果,最后在后边加一个chrome,问题竟然解决了 "start":"webpack-dev-server--openchrome" ...
  • VSCode构建WebPack项目

    2019-12-25 15:31:45
    文章目录什么是LayUI什么是VSCode什么是WebPackGulp和webpack区别VSCode构建普通项目步骤--待测试VSCode构建WebPack项目步骤1. 新建空文件夹2. VSCode打开相应文件夹3. webpack初始化4. 配置出入口文件,并自动打包...
  • vscodewebpack错误:无法将“webpack”项识别为 cmdlet、函数、脚本文件或可运行程序的名称。请检查名称的拼写,如果包括路径,请确保路径正确,然后再试一次。 我的webpack是本地安装 解决: 1、因为vscode下...
1 2 3 4 5 ... 20
收藏数 4,917
精华内容 1,966
关键字:

webpack 和vscode的区别