trix: NPM Module not working

Hi all,

I don’t want to make Trix difficult for people to use in their applications and I’m not opposed to providing a module for convenience. @lemonmade proposed a reasonable change (https://github.com/basecamp/trix/pull/236) and the comment I added to that thread should improve things.

Trix is built for the browser and fully embraces its offerings: native DOM manipulation APIs, custom elements (document.registerElement), and powerful utilities like MutationObserver, TreeWalker, and requestAnimationFrame. None of these things are available in non-browser environments like node.js, which is why Trix is not packaged for them. Browsers do not support module.exports, define, or require, and introducing them to Trix means introducing the first 100% non-browser-compatible code to its codebase.

We are using Trix and a custom asset bundling tool that currently has no good way of including the library in our bundle.

Placing <script src="trix.js"></script> in your document is all it takes to add Trix your site, and if you have no way to accomplish that then it’s probably worth examining your choice of tooling. Tools like webpack brought module support to the browser to make sharing code between the server and browser possible, and that’s a good thing. But please don’t assume these tools are always doing it The Right Way. Embrace the web.

I opened a PR that adds UMD support: https://github.com/basecamp/trix/pull/241. It’s not published on npm yet, but there’s a download linked in the PR you can use. I’d appreciate it if you could give a try and let me know if works with your build tool of choice.

@javan btw I’m friggin lovin’ Trix, kudos for this gem.

It does seem strange not to choose UMD for this; it makes it pretty easy to use this package in any environment, without relying on the presence of plugins that simply do what UMD does anyways. We are using Trix and a custom asset bundling tool that currently has no good way of including the library in our bundle.

@antoniobrandao Like I said, I don’t want Trix to be difficult for people to use. We’re looking into UMD support. Thanks for listening to me rant. 😁

@javan You made really great points, and I understand your concern, but still, it wouldn’t hurt to just add UMD to it. It wouldn’t change anything in it’s specific implementation. But it would greatly help the package managers connected to places where you published the module, like NPM.

It is very confusing to have a module in NPM, that cannot be loaded by Browserify. Whatever is in NPM, people expect to be able to require(“trix”) in a Browserify setup - if it’s a module for the browser. That’s where UMD will help, because then it could be loaded anywhere.

You don’t have to add node-specific, non-browser-code into the codebase, to make it UMD. It’s just a simple wrapper that will make your module more open to different loaders and environments (AMD, CommonJS, etc).

I also tripped on this. I’d much prefer an API more like Highlight.js, where very simple projects can inject a global and get to work quickly with something like:

<script src="/path/to/trix.js"></script>
<script>Trix.initEditorsOnLoad()</script>

And then in more complex, modular applications, UMD would make this possible:

import Trix from 'trix'

const myInput = document.getElementById('my-input')
Trix.addEditor(myInput)

The latter is much more natural in component-based projects using React/Riot/Vue.