Source-map

React项目中基本配置及常见坑的解决 一、创建React项目 # 全局安装脚手架 npm install create-react-app -g --save # 创建React项目 create-react-app my-app 二、实现Less文件的加载 1、暴露配置文件 # 暴露项目的配置文件 npm run eject 暴露配置文件后的目录结构 2、安装插件 # 安装less、less-loader插件 npm install less less-loader --save 4、修改配置文件 修改 config/webpack.config.js 的文件 // style files regexes const cssRegex = /\.css$/; const cssModuleRegex = /\.module\.css$/; const sassRegex = /\.(scss|sass)$/; const sassModuleRegex = /\.module\.(scss|sass)$/; // 新增less变量 const lessRegex = /\.less$/; const lessModuleRegex = /\.module\.less$/; 如图： 再在 cssModuleRegex 和 sassModuleRegex 之间添加如下代码： //

前言 　　经常会有群友问起 webpack 、 react 、 redux 、甚至 create-react-app 配置等等方面的问题，有些是我也不懂的，慢慢从大家的相互交流中，也学到了不少。 ​　　今天就尝试着一起来聊聊 Webpack 吧，旨在帮大家加深理解、新手更容易上路，都能从0到1搭建配置自定属于自己的脚手架，或对已封装好的脚手架有进一步的巩固，接下来苏南会详细讲解 webpack 中的每一个配置字段的作用(部分为 webpack4 新增)。 近两年，前端一直在以一个高速持续的过程发展，常常会有网友在调侃老了、学不动了， 虽是在调侃却又间接阐述着无奈，迫于生活的压力，不得不提速前行， 因为没有谁为你而停留，公司不会、社会不会、同伴不会……，停下可能将意味着淘汰 —— 理想很丰满，现实很骨感 ，所以让我们一起进步，共同加薪，奋斗吧骚年，加油。。 ～～吐槽过了，接着聊正事～～。 　　原谅我控制不住自己，想问下各位，昨天刚刚过去的双十一你脱单了吗？ 人生若只如初见，何事秋风悲画扇； 等闲变却故人心，却道故人心易变； 骊山语罢清宵半，夜雨霖铃终不怨。 各位大佬早安，这里是 @IT·平头哥联盟 ，我是 首席填坑官∙苏南 ，用心分享 做有温度的攻城狮。 公Z好： honeyBadger8 ，交流：912594095 entry 这个不用解释了，看名字就是知道，它就是通往天堂/地狱的

之前发现VS.NET会为压缩的js文添加一个与文件名同名的.map文件，一直没有搞懂他是用来做什么的，直接删除掉运行时浏览器又会报错，后来google了一直才真正搞懂了这个小小的map文件背后的巨大意义。 从源码转换讲起 JavaScript脚本正变得越来越复杂。大部分源码（尤其是各种函数库和框架）都要经过转换，才能投入生产环境。 常见的源码转换，主要是以下三种情况： 压缩，减小体积。 多个文件合并，减少HTTP请求数。 其他语言编译成JavaScript。最常见的例子就是CoffeeScript。 这三种情况，都使得实际运行的代码不同于开发代码，除错（debug）变得困难重重。 通常，JavaScript的解释器会告诉你，第几行第几列代码出错。但是，这对于转换后的代码毫无用处。你看着报错信息，感到毫无头绪，根本不知道它所对应的原始位。 这就是Source map想要解决的问题。 什么是Source map 简单说，Source map就是一个信息文件，里面储存着位置信息。也就是说，转换后的代码的每一个位置，所对应的转换前的位置。 有了它，出错的时候，除错工具将直接显示原始代码，而不是转换后的代码。这无疑给开发者带来了很大方便。 目前，暂时只有Chrome浏览器支持这个功能。在Developer Tools的Setting设置中，确认选中"Enable JavaScript

主要讲三个东西： Vue.js devtools开发工具的使用 使用debugger和sourcemap调试Vue组件 vscode中调试Vue组件 Vue.js devtools开发工具的使用 在Chrome或Firefox浏览器的扩展插件仓库里搜vue devtool，安装Vue.js devtools. 打开vue项目,在控制台选择vue image 可操作组件查看信息变化 image 使用debugger和sourcemap调试Vue组件 针对vue-cli webpack官方脚手架，打开build/webpack.dev.conf.js文件，找到下面这句： devtool: '#cheap-module-eval-source-map', 将其修改为： devtool: '#eval-source-map ', 要修改的地方已经都改好了，就是这么简单，惊不惊喜，意不意外。 现在是具体调试了。假设我们想调试App.vue这个组件，可以在想要调试的代码前添加debugger方法，如下图所示： image 然后运行npm run dev，启动服务后刷新页面（刷新前先把浏览器开发者工具打开），可以看到在程序进入App.vue组件mounted这个组件生命周期钩子里后，指定到debugger处时程序就被debug了。如下图所示，剩下的大家应该都很熟悉了。可以看到

本文转载于: 猿2048 网站⇒ 关于模板引擎一 前端模板引擎需要有开发时的透明性 透明性即指我在搭建好开发环境后，随手写代码随手刷新浏览器就能看到最新的效果，而不需要额外地执行任何命令或有任何的等待过程。 所以一切依赖编译过程的模板引擎并不适合前端使用，编译只能是模板引擎的一个特性，而不能是使用的前提 更严格地说，使用FileWatch等手段进行文件变更检测并自动编译也不在我的考虑范围之内，因为这会造成额外的等待， 由此可以推出，前端的模板引擎应该是具备 可在纯前端环境中解析使用 的能力的。 前端模板引擎要有良好的运行时调试能力 由于用户行为的不确定性、执行环境的不确定性、各种第三方脚本的影响等，前端很难做到完全的错误处理和跟踪，这也导致前端必然存在需要直接在线上排查问题的情况 而当问题出现在模板引擎这一层时，就需要模板引擎提供良好的调试能力 一般来说，编译后生成的函数的调试能力是弱于原先手动编写的模板片断的，因为自动生成的函数基本不具备可读性和可断点跟踪性 因此在这一点上，一个供前端使用的模板引擎应该具备在特定情况下从“执行编译后函数获取HTML”换回“解析原模板再执行函数获取HTML”的模式，即应该支持在两种模式间切换 或者更好地，一个强大的前端模板引擎编译生成的函数，可以使用Source Map或其它自定义的手段直接映射回原模板片段，不过现在并没有什么模板引擎实现了这一功能

摘要： 异常监控不复杂也不简单啊... 原文： 前端异常监控解决方案研究 作者：frustigor 前端监控包括行为监控、 异常监控 、性能监控等，本文主要讨论异常监控。对于前端而言，和后端处于同一个监控系统中，前端有自己的监控方案，后端也有自己等监控方案，但两者并不分离，因为一个用户在操作应用过程中如果出现异常，有可能是前端引起，也有可能是后端引起，需要有一个机制，将前后端串联起来，使监控本身统一于监控系统。因此，即使只讨论前端异常监控，其实也不能严格区分前后端界限，而要根据实际系统的设计，在最终的报表中体现出监控对开发和业务的帮助。 一般而言，一个监控系统，大致可以分为四个阶段：日志采集、日志存储、统计与分析、报告和警告。 采集阶段：收集异常日志，先在本地做一定的处理，采取一定的方案上报到服务器。 存储阶段：后端接收前端上报的异常日志，经过一定处理，按照一定的存储方案存储。 分析阶段：分为机器自动分析和人工分析。机器自动分析，通过预设的条件和算法，对存储的日志信息进行统计和筛选，发现问题，触发报警。人工分析，通过提供一个可视化的数据面板，让系统用户可以看到具体的日志数据，根据信息，发现异常问题根源。 报警阶段：分为告警和预警。告警按照一定的级别自动报警，通过设定的渠道，按照一定的触发规则进行。预警则在异常发生前，提前预判，给出警告。 1 前端异常