1.Molecule 在构建工具中的源码选择
2.五分钟学会发布React组件到NPM包
3.Framework层的Binder（源码分析篇）
4.Android 坑档案：迷失的 FileDescriptor
5.compileDebugKotlin FAILED和aidl

Molecule 在构建工具中的选择

       构建工具在前端开发中扮演着至关重要的角色，它负责将源代码转换为线上可执行的源码JavaScript、CSS、源码HTML代码，源码以实现高效、源码可维护的源码thinkphp兼职源码开发流程。Molecule作为一个轻量级的源码Web IDE UI框架，我们面临着选择一个合适的源码构建工具以支持其特定需求的挑战。本文将探讨Molecule构建工具选择的源码考虑因素及最终采用的方案。

       构建工具的源码选择需要满足多个条件，包括支持ESM、源码类型、源码样式以及处理其他相关文件的源码需求。分析Molecule的源码需求后，我们明确了构建工具应具备的源码关键功能。首先，我们需要将ESM书写的代码通过构建工具编译成ESM格式，以支持面向Web应用的依赖库的树摇动作用。这要求构建工具能够有效处理ESM代码，确保代码的高效性和最小化冗余。其次，助听器 源码我们需要支持输出类型，以确保代码的类型安全性和可读性。同时，构建工具应支持Sass的编译以及插件功能，以满足Sass-in-JS的需求，即在JavaScript中使用Sass导出的变量。此外，还需支持将其他相关文件如JSON、PNG等拷贝至指定目录。

       针对上述需求，我们对当前流行的构建工具进行了调研。Webpack作为老牌构建工具，功能全面，几乎能适用于所有场景，但在配置复杂度和冗余代码管理方面存在不足。Rollup作为面向JS类库的构建工具，体积较小，打包后冗余代码较少，专注于特定功能，但不支持Hot Module Replacement（HMR）。11101110源码Vite在构建速度方面表现出色，但不支持自定义插件，限制了某些特定功能的实现。Parcel作为一个面向Web应用的零配置高速构建工具，提供了便捷的使用体验，但自定义插件支持不足，尤其是对于Sass-in-JS的需求。swc和esbuild作为底层构建工具，与ESbuild基于Go、swc基于Rust的特性，提供了快速的JavaScript编译能力，但在特定功能和使用场景上可能不如更成熟的构建工具。babel在JavaScript转换方面表现良好，但速度相对较慢，tsc则在类型支持方面具有优势，同时也能支持输出类型文件。

       考虑到大多数构建工具的局限性，我们决定采用esbuild、Sass和tsc的组合方案。esbuild作为Compiler部分，mro源码负责快速、高效地编译JavaScript代码；Sass用于处理SCSS文件的编译，满足样式需求；tsc负责编译出类型文件，确保代码的类型安全。通过这种方案，我们能够高效地满足Molecule的构建需求，同时保持代码的可维护性和性能。

       在构建工具的选择中，我们特别关注了功能性、性能、配置复杂度、社区支持以及与特定开发需求的匹配程度。通过综合评估，esbuild、Sass和tsc的组合方案脱颖而出，提供了高效、灵活且易于集成的解决方案。除此之外，我们还解决了tsx相关文件输出、样式文件输出以及类型文件的监测 源码异步输出问题，确保了构建流程的完整性。此外，我们还鼓励社区成员就构建工具选择及使用过程中遇到的问题进行讨论，以共同推动技术进步和最佳实践的分享。

五分钟学会发布React组件到NPM包

       前言

       最近在做的项目需要实现一个可拖拽、可设置大小、并且在指定范围内才可以移动的需求，在翻了一些组件后，发现需要三样都满足,并且能满足项目定制化需要的插件几乎没有~，于是自己动手实现了该插件，整体效果如下：

       在写完之后，突然想到可以放到NPM库中，以后维护该组件更加方便版本管理，于是趁五一长假，终于将包发布上去了~

       文档地址

       NPM包地址

GitHub主页

       在发布NPM时踩了一些坑，比如脚手架打包后TS提示消失、比如NPM的官方源换成了HTTPS让发包失败等等因素导致整个过程非常不顺。

       为了避免自己未来继续踩同样的坑，或许同时还能够帮助别人节省一点时间，于是才有了这篇博客。

       如果你希望未来想用React+TypeScript完成一个组件库并发布到NPM

       如果你想了解我在发布时踩了哪些坑

       那么这篇博客适合你，阅读时长大约五分钟。

       下面是正题。

脚手架工具

       采用React+TypeScript实现的组件需要借助打包工具将代码打包好才能够被引入，我在查了一些资料后发现有以下三款工具：

       TSDX

       create-react-library

       dumi

       这三款工具都预设好了打包工具，比如dumi用的webpack、tsdx用的parcel,而且也基本实现了0配置，我们只需要根据官方文档就可以很快地完成组件编写、用例测试、打包等环节。

       其中create-react-library已经很少维护了，所以我没试过它。

       tsdx和dumi带给我的体验差不太多，而且发布最重要的其实是写文档，两款工具都有对应的文档工具，tsdx内置的是storybook，我写的第一个组件库就是用的它，但是实在太难配插件了~

tsdx的问题

       一开始我用的tsdx，但是发现几个问题：

       问题一：

       我的组件在测试用例时，无法触发ts的提示，然后我发现它打包后的声明文件中需要将：

import?react?from?'react'

       修改成：

import?*?as?react?from?'react

       我的组件才能够有类型提示。

       问题二：

       tsdx中修改组件源代码后，需要手动再次打包，然后删掉example文件夹内的node_modules文件以及.parcel_cache文件夹生成新的dist目录，才会有效果。换言之它的watch模式貌似有问题？

dumi的问题

       于是我试了一下dumi,dumi写文档的方式对我而言要比tsdx的storybook方便,不过它也有一点缺陷：

       即使用了官方推荐的ts-in-markdown插件，在写组件demo时，也是没有api智能提示的，只能提示有没有语法错误之类的。

       这个缺陷就使得写demo时没有办法知道当别人用你的组件时，有没有代码自动提示。（自动提示props真的很重要啊！！）

       不过最终我找到了解决这个问题的方法，方法在本地测试组件。

我最终选择dumi

       从结果来说使用dumi打包完的组件还是有类型提示的，不需要我手动改dist目录。

       我的组件文档首页目前是这样的：

       基本满足了我的需求，所以下面讲讲如何使用dumi的发布过程。

一些微不足道的经验

       如何使用dumi这里就不多说，看官方文档就好，我在这里讲一下我遇到的问题以及解决方法：

       当组件的props类型与外部引入的组件的props类型合并后，写API时会默认将所有props的api都展示出来。

       这一点我们需要在.umirc.ts中配置apiParser:

apiParser:?{ ?propFilter:?{ //?是否忽略从?node_modules?继承的属性，默认值为?falseskipNodeModules:?true,//?需要忽略的属性名列表，默认为空数组skipPropsWithName:?[],//?是否忽略没有文档说明的属性，默认值为?falseskipPropsWithoutDoc:?false,?},},

       当配置publicPath或base后，如果logo和favicon用的本地，一定要在前面加上publicPath或base的路径。

favicon:?'/react-drag-resizable/lightbulb.png',logo:?'/react-drag-resizable/lightbulb.png',base:?'/react-drag-resizable/',publicPath:?'/react-drag-resizable/',

       否则部署后logo和favicon的会引入失败。（这点在开发环境下发现不了）

       dumi官方给的github-pages-action自动部署的yml文件有问题官方给的yml文件是这样写的：

name:?github?pages

       on:push:branches:

       master#defaultbranch这里有问题，需要改成main

       main#这才是正确的

       jobs:deploy:runs-on:ubuntu-.steps:

       uses:actions/checkout@v2

       run:npminstall

       run:npmrundocs:build

       name:Deployuses:peaceiris/actions-gh-pages@v3with:github_token:${ { secrets.GITHUB_TOKEN}}publish_dir:./docs-dist

       官方给的自定义导航、分组和标题写法有问题

       官方写法如下：

---title:?自定义页面名称nav:?path:?/自定义导航路由?title:?自定义导航名称?order:?控制导航顺序，数字越小越靠前，默认以路径长度和字典序排序group:?path:?/自定义分组路由，注意，分组路由?=?导航路由?+?自己?title:?自定义分组名称?order:?控制分组顺序，数字越小越靠前，默认以路径长度和字典序排序---

       有效的写法：

---title:?自定义页面名称nav:path:?/自定义导航路由title:?自定义导航名称order:?控制导航顺序，数字越小越靠前，默认以路径长度和字典序排序group:path:?/自定义分组路由，注意，分组路由?=?导航路由?+?自己title:?自定义分组名称order:?控制分组顺序，数字越小越靠前，默认以路径长度和字典序排序---

       看出差别了吗？?

       已经将必要的模块导出，但写docs时引入该模块依然报错比如我已经在src/index.ts中导出组件内的类型声明和导出组件了：

export?type?{ ?RectProps,?DragResizableBoxProps?}?from?'./react-drag-resizable';

       export{ defaultasDragResizableBox}from'./react-drag-resizable';

但是在写?doc?时，正常引入`RectProps`，还是报错了。执行`npm?run?build`打包出一个?dist?文件夹，然后重启?vscode?解决。#?使用github-actions自动化部署我们可以使用?github-actions?自动化将?dumi?的组件文档部署到?github-pages?中，实现步骤如下：1.?在?github?建一个代码仓库2.?到github?的个人主页申请一个?token3.?选择token?的?note和过期时间4.?权限选择5.?最后生成?token，将token?复制到你的个人仓库的?`setting/secrets`?中我在这里使用的是?`ACCESS_TOKEN`,也可以自己写，不过这里的名字需要跟后面的?yml?文件保持一致。6.?在你的项目根目录中创建目录和?yml?文件

       .github└──workflows└──gh-pages.yml

yml文件中这样写```ymlname:?github?pageson:?push:branches:?-?main?#?default?branchjobs:?deploy:runs-on:?ubuntu-.steps:?-?uses:?actions/checkout@v2?-?run:?npm?install?-?run:?npm?run?docs:build?-?name:?Deployuses:?peaceiris/actions-gh-pages@v3with:?github_token:?${ { ?secrets.ACCESS_TOKEN?}}?publish_dir:?./docs-dist

       注意最后的secrets.ACCESS_TOKEN里面的ACCESS_TOKEN就是你在github仓库中设置的token名字。

       在项目的package.json中配置homepage字段

import?*?as?react?from?'react1

       将代码推送到远程仓库，actions会自动下载依赖并打包

       最后打开你配置的homepage就可以看到部署好的文档，我的文档地址是这样的

       /中注册一个账号

       package.json中配置一些内容

import?*?as?react?from?'react4

       上面的配置是我收集到的，如果不是非常特殊的情况，我们只需要将name、description、author、version、keywords、homepage、repository修改成自己的就可以了，其他可以不动。

       修改README一个NPM包，好的README能够快速让用户知道这个包能够干什么，如何使用等。

       这里有一个github高star的项目，教人怎么写README，并提供了模板。

       地址在这：standard-readme中文

       同时我们可能还需要徽章，这里有一个徽章生成的工具网站，可以根据NPM或者github来生成徽章，我们只需要拷贝到README就可以生成徽章

       徽章生成：pileDebugKotlin FAILED和aidl

        自从入职CS，项目编译一直有个神坑报错，每次都需要clean rebuild若干次, 非常耽误时间

        简单的说， 如果在使用AIDL时需要一个自定义的数据类型， 我们一般会这么写：

        当我们写一个子类SubClass继承该类.然后在Kotlin文件中直接或者间接引用到SubClass时, 就会出现一个以下的报错

        报错发生在 app:compileDebugKotlin , 也就是kotlinc. 但是我们明明已经定义了该类. 全局搜索发现有两个 CustomParcel.java, 推测是两个同名的文件引起.

        除了我们自己写的Java文件, 另外一个肯定是aidl生成的. 引用一张图:

        在编译开始时会把aidl转化为Java文件, 接下来才会经过javac, kotlinc把JVM语言文件转化为字节码 .class 文件.

        查看aidl生成的文件, 发现是空的, 并且有一行注释: 说明这是一个 PlaceHolder, 也就是占位文件.

        网上搜到有人遇到了 相同的问题 ，问题确实发生在kotlinC编译器以aidl生成的空java文件为编译目标， 而不是真正的java类文件. 并且也给出了解决办法，升级buildTools版本.

        查看 buildTools提交记录

        提交记录: No java output for parcelable declaration. 也就是移除了以下的为自定义的aidl Parcelable类生成Java文件的设定(.0.2之前的实现)

        升级.0.3, 再次编译, 发现build/aidl目录下不再生成同名的 PlaceHolder文件了, 只剩下唯一的我们自己的文件, kotlinC这次只能用唯一的文件来编译，报错解决.

        至于为什么有时候clean rebuild能编译成功，需要探究下kotlinC的源码.

        最坑的是， .0.2就是 gradle plugin4.1默认支持的版本 ， 所以你不手动指定buildTools版本为.0.3以上就会掉进坑里.