plugins VS trunk

Next, we need to tell Rollup which of the modules used in our code are external to our library. Together with @rollup/plugin-node-resolve, this ensures that Rollup doesn't bundle those dependencies into our final bundle. The function makeExternalPredicate() generates the list of package names specified in dependencies and peerDependencies in package.json. All credit for this and a big thank you goes out to Mateusz Burzyński for providing it in this issue:

// If you have external dependencies installed from // npm, you'll most likely need these plugins. In // some cases you'll need additional configuration - // consult the documentation for details: // https://github.com/rollup/plugins/tree/master/packages/commonjs resolve({ browser: true, dedupe: ['svelte'], }), commonjs(), // In dev mode, call `npm run start` once // the bundle has been generated !production && serve(), // Watch the `public` directory and refresh the // browser on changes when not in production !production && livereload('public'), // If we're building for production (npm run build // instead of npm run dev), minify production && terser(), ], watch: { clearScreen: false, },

In Webpack 5, this is (surprisingly) simple to setup. Parcel 2 handles this out of the box with a special import prefix. Rollup has an official plugin.

The only workaround to have an isomorphic __dirname or __filename to be used for both "cjs" and "esm" without using build-time tools like @rollup/plugin-replace or esbuild "define" would be using a library like filedirname that does a trick inspecting error stacks, it's clearly not the cleanest solution.

import svelte from 'rollup-plugin-svelte'; import commonjs from '@rollup/plugin-commonjs'; import resolve from '@rollup/plugin-node-resolve'; import livereload from 'rollup-plugin-livereload'; import { terser } from 'rollup-plugin-terser'; import css from 'rollup-plugin-css-only'; import sveltePreprocess from 'svelte-preprocess'; const production = !process.env.ROLLUP_WATCH; function serve() { let server; function toExit() { if (server) server.kill(0); } return { writeBundle() { if (server) return; server = require('child_process').spawn( 'npm', ['run', 'start', '--', '--dev'], { stdio: ['ignore', 'inherit', 'inherit'], shell: true, } ); process.on('SIGTERM', toExit); process.on('exit', toExit); }, }; } export default { input: 'src/main.js', output: { sourcemap: true, format: 'iife', name: 'app', file: 'public/build/bundle.js', }, plugins: [ svelte({ preprocess: sveltePreprocess({ sourceMap: !production, postcss: { plugins: [require('tailwindcss'), require('autoprefixer')], }, }), compilerOptions: { // enable run-time checks when not in production dev: !production, }, }), // we'll extract any component CSS out into // a separate file - better for performance css({ output: 'bundle.css' }), // If you have external dependencies installed from // npm, you'll most likely need these plugins. In // some cases you'll need additional configuration - // consult the documentation for details: // https://github.com/rollup/plugins/tree/master/packages/commonjs resolve({ browser: true, dedupe: ['svelte'], }), commonjs(), // In dev mode, call `npm run start` once // the bundle has been generated !production && serve(), // Watch the `public` directory and refresh the // browser on changes when not in production !production && livereload('public'), // If we're building for production (npm run build // instead of npm run dev), minify production && terser(), ], watch: { clearScreen: false, }, };

Even for JSON files, rollup needs an aditional library - a json plugin. The installation & configuration will be covered below.

If I do the same steps with vite everything seems to work fine. What am I doing wrong? I have tried using the wasm package from rollup @rollup/plugin-wasm but have not been successful.

And then one Rollup plugin to integrate Babel:

@rollup/plugin-babel: Triggers the transpile step through Babel (basically what we have done by means of the babel-cli for the unbundled versions). As we are using babel only for the bundled artifacts babelHelpers are set to bundled, so in case any helpers are needed these are added to the bundle file (you can read more about the property in the documentation). In include and extensions the files and their extensions (ts/js for the example library) to process are defined, whereasexcludes indicates folders/patterns which should be skipped (just the node_modules folder for the example library).

In case you're planning to build a SPA project(Single Page Application), you can use the createSpaConfig in Rollup configuration. Also, you can install the @rollup/plugin-typescript for seamless integration between Rollup and TypeScript.

Note that Leptos uses Trunk to serve the client side application. Trunk is a zero-config Wasm web application bundler for Rust.

Trunk, the Rust-equivalent of Webpack & Vite, comes with tailwind built-in. You heard that right! You don't even need to install the tailwind CLI via npm or something like that. No more package.json! <3

Can you not use dioxus with "trunk" (https://trunkrs.dev/) ?

Thanks a lot! As I said in an earlier comment, building this allowed me to explore a lot of features of rust like Traits, Dynamic Dispatch, Pattern Matching, Const evaluation, Static variables, etc. and that on top of that trying to figure out how to conveniently port it to WASM was also a nice learning experience. I am currently using trunk as a bundler which ties in neatly with a GitHub action but before that, I tried cargo-run-wasm, which felt a little hacky. So overall a whole lot of learning.

Here here. I don't think programmers - as a group - get to complain about people not learning programming tools while simultaneously making them so unapproachable (especially Linux things).

It's not just the overuse of acronyms. There's also:

* Religious devotion to the CLI despite it having terrible discoverability.

* Really bad naming. Git is probably the worst offender at this, but the whole of Unix is a naming mess. WTF is `usr`? Is that where user files go?

* Generally over-complicated tooling. A good example of this is Node/NPM. So complicated to set up! Contrast it with https://trunkrs.dev/

* Deification of distro packages. No I do not want to spend half of my development time packaging my app for 10 different distros. I guess I'll go with curl | bash then.

* Distain for binary app distribution. I'm looking at you glibc.

Hi, the author of MailCrab here :-) Yew is nice, especially if you enjoy writing Rust. However, it definitely takes more time and dedication than writing a frontend in React, Vue etc. Yew and the surrounding ecosystem keeps improving, and it is way more usable than when I first tried it. The tooling I used (Trunk https://trunkrs.dev/) is very minimal with respect to the number of features compared to many of the popular web-bundlers (Webpack etc.) but it works well for most simple use-cases.

Yew is way way nicer in that regard because it uses Trunk which is very excellent and you don't have to deal with any of that really. Just trunk serve and away you go. Plus you get the advantage of not having to deal with Javascript. Typescript is nice, but it's no Rust.

The alternative to wasm-pack is trunk. I've never used it, so I can't tell you how good it is.

My current tooling is based on using trunk which eframe supports quite easily. Notan could too I suppose. The biggest block in tooling was needing to call notan_main on the wasm module. Trunk (as far as I am aware) does not support that behavior.

I read through the trunk docs and there isn't any explicit reference to using it within a cargo workspace, however trunk includes a few clever features I discovered reading its example config file... So my thinking now is that I will put Trunk.toml in the project root, add index.html to the /client/ directory and point trunk at it, put the trunk output into /dist/