Picasso turns a Sketch artboard into Web, mini program or React Native code

What Picasso produces, and for whom

Picasso is a Sketch plugin that parses a design file and writes front end code from it. The project description in Chinese says it is a plugin offering a full flow solution for turning UI into code, and the README is blunter about the aim, describing the output as front end code that restores the design accurately and is usable. The audience is a team that has a finished design and wants the first version of the page in code before a front end engineer rebuilds it properly.

The generated artefacts come in four flavours, and the choice matters more than it first appears. There is Web code in a normal version and in an operations version, plus WeChat mini program code and React Native code. The README describes the two Web targets in terms of layout strategy rather than styling. The normal Web version is said to have a sensible structure and high usability, and is aimed at mobile list and detail pages. The operations version uses absolute positioning and has a high degree of restoration accuracy, and is aimed at campaign pages and static pages.

That split is the core engineering decision in the project. A list page needs a flow layout, because content length varies and the page is reused; a campaign page is a fixed composition where pixel accuracy is the goal. Generating one from the other would get one of the two cases wrong, so the plugin asks which one you want.

The code generation itself is driven by artboard selection. The plugin offers generating code for the currently selected artboard, or for all of them, so a designer can export a single frame or a whole flow in one pass.

Two products in one repository: the plugin and the parse engine

The repository has two layers, and the README explains the split explicitly. The plugin body lives in src/, written in CocoaScript and JavaScript, and it is responsible for extracting layers, preprocessing images, fonts and symbols, and writing the output files to disk. The resources/ directory holds the WebView user interface, which includes the design specification screens and the help centre, and assets/ holds the plugin icons and other static resources.

The second layer is packages/, a TypeScript monorepo that holds the parsing engine. The README lists the packages and their roles. picasso-parse is the only entry point published to the outside world, under the npm name @wubafe/picasso-parse. picasso-code-browser is the cross platform code generator, picasso-dsl holds the intermediate DSL types, picasso-group does feature grouping, picasso-layout does layout calculation, picasso-trans handles colour, unit and CSS order conversion, and sketch-dsl holds the type layer for Sketch's raw JSON. Every package except picasso-parse is marked private, and picasso-parse bundles the sibling packages into its tarball at compile time, so exactly one npm package comes out.

The design is a real separation of concerns. The Sketch specific code stays in the plugin, the interesting code, parsing, layout and conversion, is plain TypeScript that could be tested without Sketch. The DSL package in the middle is what makes that possible, an intermediate representation that both the Sketch JSON and the code generator can speak.

The parse engine is published on its own, with a version bump rule

The plugin depends on the parse engine as an ordinary npm dependency, pinned in the root package.json to a specific patch release of @wubafe/picasso-parse. That pin is the mechanism that makes the two layers work together, and it comes with a rule the README states plainly: after you change the parsing logic under packages/, you have to rebuild picasso-parse and bump the version of @wubafe/picasso-parse in the root directory, otherwise the plugin will not see the change.

The engine build is a small TypeScript workflow:

cd packages/picasso-parse
npm install
npm run build       # tsc → dist/，会同时把 sibling 包的源码编进 dist/
npm publish         # 发布 @wubafe/picasso-parse

The comment on the build line is worth translating, because it explains the packaging: tsc compiles to dist/, and the sibling packages' source is compiled into that dist as well. That is the mechanism behind the single published tarball, and it is also a constraint, since the engine cannot be consumed piecemeal by another project without going through the published entry point.

For a team that wants to script the plugin rather than click through it, this split is the interesting part. The parse engine is a published npm package, so the extraction and code generation could in principle be driven from a script, and the repository even contains a code browser package for cross platform generation. The README does not describe a command line entry point for that, so the supported path today is the plugin inside Sketch.

Installing the plugin, and the Sketch version it needs

The prerequisite is explicit: Sketch 60 or newer, with a link to download Sketch. The plugin itself ships as a zip, picasso.sketchplugin.zip, linked from the releases page, and the installation is the familiar one for a Sketch plugin: unzip the archive and double click the installer, after which the plugin appears inside Sketch. The README then shows a screenshot of the plugin in use, which is as much documentation of the flow as the text provides.

The package metadata encodes the same requirement. The engines field asks for a Sketch version of 60.0 or above, and the skpm block points the manifest at src/manifest.json, the main entry at picasso.sketchplugin, and the assets entry pointing at the assets folder. The skpm toolchain is what produces the bundle, and the scripts show the whole developer loop:

# 安装依赖
npm install

# 启动开发监听
npm start

# 一次性打包到 picasso.sketchplugin/
npm run build

# 清掉已安装版本并重新装入本地 Sketch
npm run reload

The reload script in package.json does the reinstall for you. It removes the installed plugin from the Sketch application support directory with rimraf and then rebuilds straight into that location, so a change in src/ is visible after a reload. Two details in the scripts are worth a maintainer's attention rather than a user's: the dev script writes its watch output to a plugin named hotwheels.sketchplugin rather than picasso, and the postinstall hook builds and links the plugin, so a plain npm install already compiles the bundle.

Maintenance, licence and the limits of the Sketch-only path

The licence is MIT, with the LICENSE file at the repository root, and the author of the package is listed as sunilwang with the repository under the wuba organisation, which is the GitHub home of 58.com. The project also has a public site at picassoui.58.com.

The maintenance record is the part that deserves attention. The last push to the repository was on 2026-08-14, so the code is still being worked on, but the newest tagged release is v2.2.3 from 2021-09-29, with v2.1.6 and v2.1.5 from June 2021 before it. The version in package.json is 2.2.3, matching that release. So the source has moved on since 2021 while the published plugin has not, and the engine dependency is pinned to 0.0.44, a patch version of a package whose published history the README does not describe. For a tool that sits between a design tool and a codebase, that gap is the practical risk: a Sketch release could change the plugin API without the plugin being rebuilt for it.

The narrower limit is the platform itself. Everything happens inside Sketch, so the output can only be as good as the design file. Layers that a designer used for visual grouping, a background rectangle behind a title for instance, are not semantic elements, and a parser that reads geometry has to guess what each rectangle was for. That is why the README separates the two Web targets rather than trying to produce one good output, and it is why generated code from a design tool is normally treated as a first draft.

The alternative approach is the component library, where designers work with the same components the code uses, so a page is assembled rather than parsed. That approach costs an upfront investment in a design system and a shared component package, and it removes the guesswork entirely. Picasso is cheaper to start with and cheaper to abandon, and it will always produce code that a human has to refactor, while the component approach produces code that is often already correct. For a company already maintaining a component library in code, the parsing step is work that has already been done elsewhere.

One small sign of how the repository is used: the root contains an.appcast.xml file and a file with a timestamp name, 1632896073866.zip, sitting at the top level. Neither is documented in the README, and both suggest a working directory rather than a curated source tree.

Editorial conclusion

Adopt Picasso if your team works in Sketch, needs a fast first pass of page structure, and can treat the generated code as a starting point rather than a finished component. Do not adopt it as a design to code pipeline you can build on top of, because the parse engine is published at a pinned patch version, the last tagged release is v2.2.3 from 2021-09-29, and the plugin only runs inside Sketch 60 or newer on macOS. Verify first by generating the same artboard in both Web targets and comparing the layout strategy, then read the layout calculation in packages/picasso-layout before you commit to absolute positioning in the operations version.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. wuba/Picasso on GitHub