
Research
wget to Wipeout: Malicious Go Modules Fetch Destructive Payload
Socket's research uncovers three dangerous Go modules that contain obfuscated disk-wiping malware, threatening complete data loss.
本工具提供了项目前端代码的优化输出和自动化发布功能,本工具的主要特性有:
发布工具基于nodejs平台,因此需要使用者先安装nodejs环境,nodejs在各平台下的安装配置请参阅官方说明。
注:打包工具从1.0.0版本之后,需要nodejs在0.12.x以上的版本
执行以下命令安装打包工具,如果已安装打包工具可忽略此步骤
npm install nej –g
如果已安装过打包工具,则可以使用以下命令更新打包工具至最新版本
npm update nej –g
执行以下命令初始化打包配置文件,命令后面可输入配置文件输出路径,默认输出在当前目录,此时会在指定目录或者当前目录生成一个release.conf文件用来配置打包选项
nej init
nej init /path/to/deploy/dir/
按照项目的实际情况修改配置文件release.conf,具体参数见手册配置参数章节
执行以下命令打包项目,如果release.conf文件在当前目录也可不指定
nej build
nej build /path/to/release.conf
打包标记说明见 wiki
精灵图合并说明见 wiki
release.conf 文件配置参数说明见 wiki
cache.json 文件配置参数说明见 wiki
本工具使用时在终端或者命令行输入以下格式指令运行
nej [指令] [参数]
其中可用的指令包括:
指令 | 描述 |
---|---|
init | 创建release.conf配置文件 |
build | 根据release.conf配置文件发布项目 |
export | 导出指定脚本文件列表 |
cache | APP 发布到 Web Cache 服务器 |
其中针对nej可用的参数包括:
简写 | 全称 | 描述 |
---|---|---|
-v | --version | 显示工具版本信息 |
-h | --help | 显示指定命令的帮助信息 |
使用范例:
查看工具版本信息
nej -v
显示工具帮助信息
nej -h
查看build指令帮助信息
nej build -h
在指定目录下输出release.conf文件模板,后续可在此基础上调整配置参数,指令的运行格式为:
nej init [目录] [参数]
其中 [目录] 为配置文件的输出目录,相对路径相对于当前执行命令的目录,默认在当前目录下输出
针对 nej init 指令可用的参数包括:
简写 | 全称 | 描述 |
---|---|---|
-h | --help | 显示 init 命令的帮助信息 |
使用范例:
在当前目录下生成 release.conf 文件
nej init
在 /path/to/output/ 下输出 release.conf 文件
nej init /path/to/output/
使用指定的配置文件打包项目,指令的运行格式为:
nej build [配置文件] [参数]
其中 [配置文件] 为通过 "nej init" 生成的项目配置文件路径
针对 nej build 指令可用的参数包括:
简写 | 全称 | 描述 |
---|---|---|
-h | --help | 显示 build 命令的帮助信息 |
-m | --mode | 发布模式,此优先级高于配置文件中X_RELEASE_MODE配置的优先级,默认为online |
-l | --level | 日志级别,此优先级高于配置文件中X_LOGGER_LEVEL配置的优先级,可用值:debug,info,warn,error,all,off,默认为all |
使用范例:
通过当前目录下的 release.conf 文件发布项目
nej build
使用 /path/to/release.conf 配置文件发布项目,并使用 test 模式,仅输出 warn/error 的日志
nei build /path/to/release.conf -m test -l warn
导出指定的脚本文件列表,多个脚本用逗号分隔,指令的运行格式为:
nej export <脚本列表> [参数]
其中 <脚本列表> 为脚本路径的列表,支持多个脚本文件输入,脚本文件之间使用逗号分隔,脚本文件路径支持NEJ依赖系统规范,支持NEJ依赖分析
注意:脚本路径中出现的 “&” 符号因为是命令行关键字,需使用 “%26” 代替
针对 nei export 指令可用的参数包括:
简写 | 全称 | 描述 |
---|---|---|
-h | --help | 显示 update 命令的帮助信息 |
-o | --output | 指定导出脚本文件的路径,相对路径相对于当前目录,默认在当前目录生成output.js文件 |
可扩展的配置参数,后续根据实际需求扩展
简写 | 全称 | 描述 |
---|---|---|
无 | --charset | 文件输入输出编码,默认utf-8 |
无 | --dropconsole | 输出代码是否删除console相关日志输出代码,默认不删除 |
无 | --codeWrap | 输出代码包装语句,其中%s表示输出代码,默认为 %s |
使用范例:
导出当前目录下的 a.js和b.js 输出到 /path/to/min.js
nej export ./a.js,./b.js -o /path/to/min.js
导出NEJ模块到 /path/to/app.min.js 文件
nej export /path/to/nej/define.js?pro=./src/%26com=./src/common/,util/ajax/xdr,./app.js -o /path/to/app.min.js
将需要 Web Cache 缓存的资源发布到服务器,如果当前目录在 cache.json 所在目录可以不传参数,指令的运行格式为:
nej cache [配置文件] [参数]
针对 nej cache 指令可用的参数包括:
简写 | 全称 | 描述 |
---|---|---|
-h | --help | 显示 cache 命令的帮助信息 |
-k | --token | 上传接口使用的验证Token |
-i | --appid | 产品在 Web Cache 服务器上的标识 |
-n | --nativeId | 产品下的某个应用在 Web Cache 服务器上的标识 |
-l | --level | 日志输出级别,可用值:debug,info,warn,error,all,off,默认为all |
使用范例:
通过当前目录下的 cache.json 文件发布项目
nej cache -k werasdfasdferwr -l info
使用 /path/to/cache.json 配置文件发布项目,命令行配置的 token、appid、nativeId 优先级高于 cache.json 文件里配置的优先级
nej cache /path/to/cache.json -k erqwerqwerqwer -i 220000 -n 3456789
Q:如何在非NEJ项目中使用打包工具?
A:
如果需要指定打完包后的样式/脚本插入位置,则可以在页面中增加 style 和 script 打包标记,标记说明,如果使用自动处理可忽略,自动处理时插入点为第一个参与打包资源的位置
<html>
<head>
...
<!-- 在要打包后插入样式的位置加入style标记 -->
<!-- @style -->
<link href="/src/css/a.css" .../>
...
</head>
<body>
...
<!-- 在要打包后插入脚本的位置加入script标记 -->
<!-- @script -->
<script src="/src/js/a.js"></script>
<script src="/src/js/b.js"></script>
<script src="/src/js/c.js"></script>
<script src="/src/js/d.js"></script>
<script src="/src/js/e.js"></script>
...
</body>
</html>
Q:服务器模版项目中如何使用打包工具?
以freemarker为例,其他模版类似
原先core脚本配置文件core.js.ftl
<#macro coreJS>
<script src="/src/js/a.js"></script>
<script src="/src/js/b.js"></script>
<script src="/src/js/c.js"></script>
<script src="/src/js/d.js"></script>
<script src="/src/js/e.js"></script>
<script src="/src/js/f.js"></script>
</#macro>
原先页面入口模版page.ftl
<@coreJS/>
<script src="/src/js/pg/a.js"></script>
<script src="/src/js/pg/b.js"></script>
<script src="/src/js/pg/c.js"></script>
A:采用打包配置方式来实现
方式一:在打包配置文件中打开 CORE_LIST_JS 配置参数,并将core.js.ftl中的js文件列表配置在该参数中
CORE_LIST_JS = ['/src/js/a.js','/src/js/b.js','/src/js/c.js','/src/js/d.js','/src/js/e.js','/src/js/f.js']
方式二:合并策略开关 CORE_MERGE_FLAG 设置为 2 或者 3,让每个页面的脚本单独分析
CORE_MERGE_FLAG = 2
Q:如何在使用RequireJS加载器的项目中使用打包工具?
A:可以按照以下步骤对RequireJS项目做打包输出
对页面引入的requirejs脚本增加noparse标记
<!-- @noparse -->
<script data-main="scripts/main" src="scripts/require.js"></script>
<!-- /@noparse -->
配置打包参数 CORE_NOPARSE_FLAG 为2,不对内联脚本做任何解析
CORE_NOPARSE_FLAG = 2
使用RequireJS的打包工具r.js对项目进行打包输出
针对输出结果配置打包参数,包括输入输出配置等
执行打包命令对样式和静态资源等内容做优化输出
Q:如何在代码中植入调试信息
A:编码时使用DEBUG标识区分开发调试代码片段
var a = 'aaaaa';
if (DEBUG){
// 这里的代码片段在打包发布时会自动删除
console.log('info for test');
}
// TODO something
Q:为什么我在windows、mac系统下用nej build可以正常打包,但是在linux下打包会报JS语法错误
A:这种情况下多半是因为你依赖的文件路径名称中有大小写搞错了,你可以根据提示在打包配置文件下找到出异常的JS文件,然后找到对应行看一下出错的文件路径是什么,比如以下打包异常提示
[E] 2016-03-01 17:05:12.076 - js code parse error for pp_app.js, source code in pp_app.js, exception information :
Unexpected token: name (read) at line 55 col 5
则可以在release.conf文件所在的目录下找到 pp_app.js 文件,查看第55行查看异常信息,如
55: cant read file E:/workspace/nej-toolkit/test/cases/abort/webapp/src/javascript/not/exist.js for utf-8, cause:
56: {"errno":-4058,"code":"ENOENT","syscall":"open","path":"E:\\workspace\\nej-toolkit\\test\\cases\\abort\\webapp\\src\\javascript\\not\\exist.js"}
Q:如何用 Sublime Text 优雅的查看配置文件
A:使用 Sublime Text 打开配置文件,点击编辑器右下角,选择始终使用 Java -> Java Properties 语法高亮该扩展名的配置文件,如下图所示
Q:如何用 WebStorm 优雅的查看配置文件
A:使用 WebStorm 的 Jodd Props 插件来查看,具体操作步骤如下图所示
在菜单 File -> Settings 中打开 WebStorm 的配置
在设置窗口左侧中找到 Plugins 菜单项,点击 Browse repositories... 按钮
在搜索框里输入 prop 关键字搜索插件,并安装找到的插件
重启 WebStorm
在菜单 File -> Settings 中打开 WebStorm 的配置,并选择左侧的 Editor -> File Types 选项,找到 Jodd Props 文件类型,并将 *.conf 添加到此文件类型的识别规则中
FAQs
frontend publish toolkit
We found that nej demonstrated a not healthy version release cadence and project activity because the last version was released a year ago. It has 1 open source maintainer collaborating on the project.
Did you know?
Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.
Research
Socket's research uncovers three dangerous Go modules that contain obfuscated disk-wiping malware, threatening complete data loss.
Research
Socket uncovers malicious packages on PyPI using Gmail's SMTP protocol for command and control (C2) to exfiltrate data and execute commands.
Product
We redesigned Socket's first logged-in page to display rich and insightful visualizations about your repositories protected against supply chain threats.