Here is some text: {漢字|かん|じ}.
HTML cooked = PrettyText.cook markdown.strip expect(cooked).to eq(html.strip) end ``` Not surprisingly, the failure says it’s getting the cooked text as if the markdown still applied. ```plaintext expected: "Here is some text: {漢字|かん|じ}.
" got: "Here is some text: 漢字.
" ``` --- What I usually do in cases like this is start printing stuff out. Have you tried adding some internal `console.log` statements outputting vars, they may help shed some light here. I do believe the settings are send down to the markdown engine, your test does look legitimate. --- It’s been a while since I’ve done some good old console log debugging. I’ll give that a shot. --- I am very much a [puts debugger](https://tenderlovemaking.com/2016/02/05/i-am-a-puts-debuggerer.html) it is the mechanism I find I fallback to most of the time. --- I figured out the issue. It was in fact a problem with how I was using `opts.features` as I suspected. After looking at the [core markdown code](https://github.com/discourse/discourse/blob/1c179177e7c84362572481e61b18597f7d2d5050/app/assets/javascripts/pretty-text/engines/discourse-markdown-it.js.es6), I realized that the feature name is based on the file name. I had my file named `markdown-ruby.js.es6`, so the feature name was implicitly `markdown-ruby` even though I was assigning the feature `ruby` in my code. Renaming the file to `ruby.js.es6` resolved the issue. It’s still a little unclear to me if the `opts.features` I’m modifying represents all features or just the markdown subset of features. If it’s all features, `ruby` feels a little too short/vague and I might rename the file and feature to `markdown-ruby` just to be safe.