does trunk support install and build npm package

[ensonmj]

hi
I have a yew project with npm package material-components-web as a dependency.
now I use parcel to build the project.
Does trunk support this dependency management?
thx

[thedodd]

@ensonmj great question. If you are just pulling in web-ready JS, then yes, Trunk already supports this. Check out the README on the section about rel="trunk-dist". This will allow you to pull in any other resources and add them to your dist directory.

However, Trunk does not currently have support for doing JS/TS transpilation or anything like that. It is possible that we might be able to add support for doing this with something like SWC, which I think would be pretty cool. At this point, I haven't even started planning that feature yet.

Does your use of material-components-web require JS transpilation/compilation?

[MartinKavik]

Trunk does not currently have support for doing JS/TS

TS compiler would be nice. If I have to write JS (e.g. web components, Rust/JS library bridges, ..) I would rather use Typescript.

[thedodd]

TBH, the thing which I am concerned about, and which so far I have really wanted to avoid, was getting into the JS/TS compilation/transpilation game. I feel like doing so would require a fair amount of work, and would detract from Trunk's core focus, which is "Rust first".

I definitely think there is room for shelling out to something like swc, however we will need a way to manage the installation of a tool like that, and from what I can tell, it looks like it expects npm to be present. That is a bit of a 🚩(red flag) for me.

@MartinKavik @ensonmj (and of course anyone else) any feedback on what your preference would be here? What do you think would be a good balance for Trunk?

[ensonmj]

TBH，I don't know much about npm and parcel. I just use them as a tool to manage some awesome dependencies.
If trunk doesn't want to get into this field, then we can't just use only trunk on real-world projects.

[MartinKavik]

Read the last paragraph: denoland/deno#5432 (comment).

I've just refreshed my knowledge about Typescript from the era when I was a back-end Typescript developer and I'm not sure we want to integrate Pandora's box with TS/Npm/Yarn/Tsc/Deno/Node/TS linters/TS formatters/* directly into Trunk.

However wasm-bindgen already supports Typescript (e.g. typescript_custom_section or typescript_type) and wasm-pack uses those wam-bindgen features to generate ts files.

So I think one way to move forward would be to write examples with Trunk and TS-related tools so users know how to setup Rust/TS projects with their favorite TS/JS tools and libraries. And we can implement some general Trunk pipeline hooks and dev server endpoints to allow communication between these tools and Trunk to make the integration easier.

To have an idea what JS/TS tools may be useful, there is a list from seed-rs.org / Seed webpack quickstart:

• PostCSS (SCSS / TailwindCSS, Autoprefixer, linters, formatters, Rust classes generator, ...)
• TS compiler
• Handlebars template compiler
• react-snap for prerendering
• netlify-cli for deploy
• lit-element for web components
• cspell for spell checking

[thedodd]

@ensonmj yea, you do make a good point that many real-world projects will have some JS/TS which needs to be processed. This is the web after all.

@MartinKavik agreed. Whatever path we take on this front, I definitely want to avoid Pandora's box.

FWIW, the main reason that I decided to create Trunk is because the typical workflow for creating a Rust WASM was a JS first workflow:

• get your typical NPM/JS app setup. Get your Webpack/Parcel/Rollup (whatever) bundler configured. Run it in watch mode.
• then get Rust project setup, have its own independent build pipeline (just for your local build process). The JS watcher wouldn't handle triggering all of the Rust build steps.

... no good. So with Trunk we take the opposite approach. Get your Rust project setup, and that's all. No node, no npm, no JS bundler needed. Long-term ... that will be even more of a strength as WASM becomes more widespread. I would like to preserve that as much as possible moving forward.

That said, we still need to be honest with ourselves about JS being around for a while. So some support is definitely needed. Leading into next comment ->

[thedodd]

@ensonmj @MartinKavik (any anyone else) what would you like to see for JS/TS integration? What do you think would be best?

1. just embprace the fact that there will be a JS/TS project around and expect them to run side-by-side?
2. require folks to put their JS/TS project in a subdirectory, and then we invoke SWC to compile/transpile the JS/TS, hash the artifacts, and then drop it all in the dist dir?
   • we could even setup special watcher config to invoke SWC only when changes under the js/ts dir are detected.
3. (edit:) additionally, not exclusive to any of the other options, we can have a simple config which will just include any JS which is already fully processed (ready for the browser) and simply include it in the dist dir (this is actually already supported right now) or potentially inline the JS in the HTML (future work).
4. ... something else.

[MartinKavik]

I think the simplest way forward would be:

1. Allow users to add custom paths to folders/files into the set of watched items (e.g. via a config file like Trunk.toml). That way Trunk will know that it should recompile Rust or at least refresh dev server / browser tab when you, for instance, generate a JS file from your recompiled TS files by your JS tools.

2. Allow users to add before / after hooks for Trunk commands like build or release_build. Users would write them as custom cross-platform scripts - see e.g. Add task build_dist seed-rs/seed-quickstart#32 (comment). That way we can invoke, for instance, TS compilation in a production mode before release_build is started.

Imho it should be enough to cover most of the cases and we can introduce other features when needed.

[thedodd]

@MartinKavik && @ensonmj once #73 lands, we will have a pretty simple path for adding some asset pipelines to accomplish this. Here are a few ideas, I'm interested to see what you folks think:

1. <link data-trunk rel="js" href="path/to/code.js" />: this pattern would just hash and copy the target JS module to the dist dir, and be ready to serve and use it. This will be dead simple, and as all of the functionality for this already exists in Trunk.
2. <link data-trunk rel="npm" href="path/to/package.json" data-build-cmd="build" data-node-version="14.13.0" />: this will be a much more involved Trunk asset pipeline. We will probably need to manage node version installation, triggering builds, watching the source &c.
3. <link data-trunk rel="swc" .../>: this is necessarily mutually exclusive with either of the previous options, but might be a nice pipeline type to add for folks using swc.

Either way, we could support all of the above options, and others long-term. Let me know what you all think. Anything critical which you think this design is overlooking? Maybe there is a better way to do this, thoughts?

[lukechu10]

A JS bundler that I particularly like is Snowpack.
Even though it is pretty new and has limited plugin support, there is a super easy way to add in an existing build pipeline using @snowpack/plugin-run-script and @snowpack/plugin-build-script.

I believe trunk should have something similar (either defined in index.html or in Trunk.toml). This would enable a wide variety of build pipelines with limited effort.

This is pretty similar to option 2 (#32 (comment)) but more flexible (imo).

Edit: In fact, this might be implemented as a plugin itself when #104 happens, whenever that may be.

[thedodd]

The hooks system #221 has recently landed which offers a nice initial form of support for this pattern. @ensonmj thoughts on this? Will this satisfy your requirements?

[Kofituo]

@MartinKavik && @ensonmj once #73 lands, we will have a pretty simple path for adding some asset pipelines to accomplish this. Here are a few ideas, I'm interested to see what you folks think:

1. <link data-trunk rel="js" href="path/to/code.js" />: this pattern would just hash and copy the target JS module to the dist dir, and be ready to serve and use it. This will be dead simple, and as all of the functionality for this already exists in Trunk.
2. <link data-trunk rel="npm" href="path/to/package.json" data-build-cmd="build" data-node-version="14.13.0" />: this will be a much more involved Trunk asset pipeline. We will probably need to manage node version installation, triggering builds, watching the source &c.
3. <link data-trunk rel="swc" .../>: this is necessarily mutually exclusive with either of the previous options, but might be a nice pipeline type to add for folks using swc.

Either way, we could support all of the above options, and others long-term. Let me know what you all think. Anything critical which you think this design is overlooking? Maybe there is a better way to do this, thoughts?

Any update on this?
Does it work now?

[github-actions]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.