| Repository | Link |
|---|---|
rollup-plugin-rust | https://github.com/DrSensor/rollup-plugin-rust |
| Example usage | https://github.com/DrSensor/example-stencil-rust |
This is a rollup plugin that makes Rust code can be used in Javascript. The main motivation I build this because I need to incorporate Rust in WebComponent module made using Stencil. This plugin is based on the webpack loader called rust-native-wasm-loader.
The main dependencies used by this project is rust-native-wasm-loader. However, rust-native-wasm-loader will not get installed when the consumer installs this plugin because only some part of that loader used by this plugin is pre-bundled. This is the reasons why rust-native-wasm-loader is in devDependencies section (and not in dependencies).
cargo.js is helper code that is product of [rust-native-wasm][] when build executedThe test framework I used for this project is Jest running on Nodejs v8 or higher. The reason the minimum Nodejs is not v6 because the WebAssembly support begins in Nodejs v8. For the approach, I implement 2 kinds of test: unit-tests and smoke-tests. The unit-tests use Jest which automatically confirms that the generated code can be run in Nodejs ≥8.x. The smoke-tests itself written as example-stencil-rust (linked as git submodule) which automatically confirm that it can be used in the front-end code. (need to figure out how to set up e2e-tests in Stencil just for my future references)
| Test | Link | environment |
|---|---|---|
| unit | https://github.com/DrSensor/rollup-plugin-rust/tree/master/test | nodejs |
| smoke | https://github.com/DrSensor/example-stencil-rust/tree/smoke-test | browser |
As usual, I use CircleCI for the automated build process. The CI workflow is based on webpack-defaults which I also use in binaryen-loader. The difference is I disable the test jobs for node6-latest and node8-canary (also add smoke-test for Stencil). For node8-canary, I disable it because there is no rollup@next or beta version yet.
This is also based on webpack-defaults which use standard-version. The difference is I split it into 2 processes:
npm run release: only for generating changelog and bumping version so I can review and change it before commit + tagnpm run release:ok: after verifying the generated changelog is correct, run this command to commit changes and make tag releaseUnder the hood, it uses commitlint to enforce the commit message so that the autogenerated changelog will always work. Summary if anyone makes changes, do commit but the message format doesn't follow conventionalcommits then it will complain and the changes don't get committed.
As many common projects out there, I use eslint + prettier to enforce code-style. One thing I added here is the linter will also run when doing commit changes. That setup was done using husky + lint-staged. Another thing that I used is flow to have static typing in my code to make it more maintainable in the long run (though I still like Typescript 😆). The thing is somehow I manage to make flow eat my RAM about 3.6GB 😂. Probably this happens because I close and open my VSCode frequently.
flow and amazed I can make that achievement 😂Something interesting that I found when generate Stencil project using create-stencil:
The official stencil template has many security vulnerability problems in their dependencies. Probably because the script doesn't perform npm audit fix after installing the dependencies.
npm audit fix after running npm init stencil components <projectName>Upon starting the generated project by running npm start
Just DM's me, make a Github issue or writes a comment below if someone interested. For guidelines, see Contributing section.