Has I said in another entry, switching to CM6 0.20 lost the highlight for markdown and yaml languages.
The editor runs in Chrome on Windows in a Vue 3 application (if this matter). Before, under 0.19 the highlighting was perfect. Here are, hoping they could help diagnosing the problem: the node_modules content, the code I use for markdown and an error that appears as soon as I start writing in the editor. A small example will follow shortly.
These are the related node_modules entries:
If I write in the editor **word** it is not rendered as per my style.
As soon as I write anything in the editor, the following error appears:
CodeMirror plugin crashed: TypeError: tags3 is not iterable
at HighlightStyle.style (index.js:227:29)
at highlightTags (index.js:244:33)
at HighlightBuilder.highlightRange (index.js:294:30)
at highlightTree (index.js:262:13)
at TreeHighlighter.buildDeco (index.js:1582:13)
at new TreeHighlighter (index.js:1564:33)
at ViewPlugin.create (index.js:1798:42)
at PluginInstance.update (index.js:1817:44)
at new EditorView (index.js:5962:20)
at loadConfigurationData (EditConfig.vue:90:12)
ο»Ώ```
Hope this is sufficient.
Thanks for looking!
mario
I have the same behavior (same exact error message) with a language that I developed (grammar, style, highlights) that worked fine in 19.x, but fails with 20.
I followed the basic guidelines for updating: moving imports for the new package layout, and wrapping styles with syntaxHighlighting(β¦).
Let me know what kind of info I can provide to help find the issue, and thanks for your help.
The error appears as soon as some text is entered
Donβt know if itβs relevant, but in my case itβs a react application, build with ViteJS.
The problem happens both in dev mode (JS source transpiled on the fly) and in production builds (assets packaged using rollup)
This is relevant! My application too is built with Vue + vite. If I compile for development the problem is the previous one. If I build for production the resulting bundled application says: Unrecognized extension value in extension set ([object Object]). This sometimes happens because multiple instances of @codemirror/state are loaded, breaking instanceof checks. Not simple to debug, but Iβll try and report back.
The message is from node_modules/@codemirror/state/dist/index.js (suggestion: add a JSON.stringify() call for ext to understand where the problem happens)
I have edited node_modules/@codemirror/state/dist/index.js to add the JSON.stringify call (bad thing, I knowβ¦) and magically no more Unrecognized extension value in extension set error, but returned the previous CodeMirror plugin crashed: TypeError: n is not iterable without applying styles.
In my opinion, this points to some module loading order problem. Iβll try to change the module order for rollup to see if anything changes. The current order (from vite.config.js) is:
Seems (magically) solved. I tried to add console.log calls to @lezer/highlight/dist/index.js and restarted development server with the --force option (npx vite --force) and now the highlight works and no more error about iterable.
Same solution for production build. Added a console.log call to @lezer/highlight/dist/index.js rebundled for production. It works. Then removed the print statements, rebundled and it worked again.
Maybe vite has some hidden cache that this way has been reloaded (there is no --force option for production).
@fbellomi let me know if this magical spell solved also your problem.
Thanks for your patience, support and knowing I was not alone with Vue+vite problems!
mario
I tried to add some console.log to @lezer/highlight/dist/index.js but it did not solve the problem, even with --force (I had already tried to clear the cache before).
Also, I need to guarantee the reproducibility of the build, since the production build will be generated in a CI/CD pipeline, not on my local machine. If the sequence of your action somewhat modified some state of the system, it is not clear to me where this state is held (afaik, vite cache is simply a cache of transpiled files)
Is this a matter of the order of the import statements / initialization? Is there a way to programmatically force the correct initialization order from the code?
I donβt know what to answer. In my case a stale cache could be the main explanation, but the fact that changing a string made the error disappears points to other problem, like related to loading order, maybe triggered by the module reorder and merging. But till the problem is not reliably reproducible I donβt know what to suggest.
changing tags with tags = [], and tags with (tags || []) in line 229
My understanding is that function is called the first time with an undefined value, and this causes the plugin to crash and be disabled; preventing this allows the function to be recalled with a suitable value
Iβm not sure what is the root cause of the problem (init order?), and why it seems dependent on the specific build system; Iβm not knowledgeable enough to address this in a more principled way.
I was facing the same issue as described. The fix proposed by @fbellomi also worked for me. @marijn Do you want me to create a pull request proposing this little fix ?
With this approach, you can avoid modifying the source code of the library, which is a good idea if you donβt want to depend on unpublished artifacts.
It requires modifying a TS constant, however
No, that is just masking an underlying problem of using mismatched library versions, it doesnβt seem reasonable to add a kludge for that to the code.
I had a similar issue when upgrading from v0.19 to v6.0.0. I have an editor for JSON in a SvelteKit+Vite project. This did throw the following error:
CodeMirror plugin crashed: TypeError: tags3 is undefined
Clearing node_modules didnβt solve anything, and there are no v0.19 packages left in my dependencies. The workaround by Francesco (May 5) works this for me, wrapping highlighter.style with a function that passes tags || [] to the original function.