Litvis broken in Atom 1.38.x and above

[jwoLondon]

It looks like the changes in Atom from 1.37 -> 1.38 have broken our markdown-preview-enhanced-with-litvis plugin.

We need to realign our fork with markdown-preview-enhanced which does work in Atom 1.38.0.

[jwoLondon]

We continue to work on this (it involves updating the underlying litvis mume fork to align with the latest mume releases). In the meantime, litvis works with atom up to and including 1.37.0. If you have updated beyond this release, it can be downgraded by installing from the assets lists at https://github.com/atom/atom/releases/tag/v1.37.0

[kachkaev]

Being addressed in

• Upgrade dependencies and refactor #34
• Sync with upstream mume-with-litvis#1
• Sync with upstream markdown-preview-enhanced-with-litvis#1

VSCode fix will follow once the plugin is working again in Atom

[kachkaev]

@jwoLondon could you please check Atom plugin v 0.17.0 on the latest Atom? I clicked through some of our examples and they appeared to be working for me.

I'll get to fixing the VSCode extension once we confirm that everything works in Atom. There'll have to be a pull request similar to gicentre/markdown-preview-enhanced-with-litvis#1.

[jwoLondon]

This is great work Alex - thanks very much.

I'll get on to testing this afternoon.

[kachkaev]

I'll be away for a 1-2 hours and will happy to look at litvis a bit more later on. If we don't have any critical fixes to do, I'll try upgrading vega to v5.6.0 and vega-lite to v4.0.0-beta.8.

Please check as many examples as you can because there've been a lot of major version bumps in dependencies. Not all packages are covered with typings, so I had to fix some of the breaking changes after seeing bugs in Atom rather than linter feedback. Hope I haven't missed anything, but glitches are still likely.

One thing I noticed is edubkendo/atom-elm#52 popping out time and again I edit an elm block in a markdown file. Disabling autocompletion in language-elm helped.

[kachkaev]

One more thing to check is Elm formatting. After npm i --global prettier prettier-plugin-elm and restarting atom, elm blocks in markdown do format for me via prettier-atom.

[jwoLondon]

Tested with completely clean install of atom and node. Following the install instructions to the letter installs the following versions from the command line:

• node --version v10.16.3

• npm --version 6.9.0

• elm --version 0.19.0

• prettier --version 1.18.2

• Atom 1.40.1

• markdown-preview-enhanced-with-litvis 0.17.0

• language-elm 1.5.0

• busy-signal 2.0.1

• linter 2.3.1

• language-markdown 0.37.0

• prettier-atom 0.57.2

A simple litvis doc with spec works and renders with no console errors.

But, as you hinted, elm-format does not work, so presumably some problem with prettier-plugin-elm. JavaScript code blocks also fail to be formatted properly, so not specific to elm.

Manual formatting from the command line works for elm and javascript code blocks:

prettier helloWorld.md --write

[kachkaev]

Can it be that your Atom is configured to use some other formatter on save by default? Is the result the same when you type Prettier: format in the cmd+shift+p menu?

[jwoLondon]

Formatting from the Atom console formats Javascript blocks correctly, but does not format elm blocks.

[kachkaev]

It could be that the Atom plugin does not pick the global prettier instance somehow. It either grabs the local prettier or fallbacks to a built-in one, which comes with Atom.

Alternatively, it can be that the global instance of prettier does not discover the plugin. If you type prettier --support-info | grep elm in a folder that does not have local node_modules, do a few rows show up? If yes, it might be worth trying to open Atom is some non-project folder (e.g. just ~), then open a single litvis file from there and finally try to format.

[jwoLondon]

prettier --support-in | grep elm in a clean folder gives

 "extensions": [".elm"],
 "parsers": ["elm"],
 "tmScope": "source.elm",
 "vscodeLanguageIds": ["elm"]

Opening atom from the command line in a non project folder and then opening a file that needs formatting still just formats the javascript blocks but not the elm blocks when formatting via ctrl-option-F

[kachkaev]

What do you see when you cmd+shift+p, Prettier: Debug? My output:

Atom version: 1.40.1
prettier-atom version: 0.57.2
prettier: /usr/local/lib/node_modules/prettier/index.js
prettier version: 1.18.2
prettier-eslint version: 9.0.0
prettier-atom configuration: {
  "formatOnSaveOptions": {
    "enabled": true,
    "respectEslintignore": true,
    "showInStatusBar": false,
    "excludedGlobs": [],
    "whitelistedGlobs": [],
    "isDisabledIfNotInPackageJson": false,
    "isDisabledIfNoConfigFile": false,
    "ignoreNodeModules": true
  },
  "useEslint": false,
  "useStylelint": false,
  "prettierEslintOptions": {
    "prettierLast": false
  }
}

/usr/local/lib/node_modules/prettier/index.js is the globally installed prettier, next to which there is prettier-plugin-elm (/usr/local/lib/node_modules/prettier-plugin-elm).

[jwoLondon]

Debug output is

Severity 	Provider 	Description	Line 
prettier-atom: details on current install

Atom version: 1.40.1
prettier-atom version: 0.57.2
prettier: bundled
prettier version: 1.18.2
prettier-eslint version: 9.0.0
prettier-atom configuration: {
  "formatOnSaveOptions": {
    "enabled": false,
    "respectEslintignore": true,
    "showInStatusBar": false,
    "excludedGlobs": [],
    "whitelistedGlobs": [],
    "isDisabledIfNotInPackageJson": false,
    "isDisabledIfNoConfigFile": false,
    "ignoreNodeModules": true
  },
  "useEslint": false,
  "useStylelint": false,
  "prettierEslintOptions": {
    "prettierLast": false
  }
}

(note bundled above)

I wonder if the cause is related to the fact that my location for global npm packages is ~/.npm-global (to avoid EACCESS problems, confgured via npm config set prefix '~/.npm-global').

[kachkaev]

Yeah that could be it. Here is how Prettier for Atom determines the global path: https://github.com/prettier/prettier-atom/blob/fbce7e8beac582e215124858a8b05d70784f8fe3/src/helpers/getPrettierPath.js#L10-L11

Under the hood we have https://www.npmjs.com/package/global-modules

Is ~/.npm-global any kind of convention? If there exists a prevalent node_module location for people with no admin rights, perhaps we could ask for a change upstream? What do you see when you type npm root -g from any directory? Possibly related: jonschlinkert/global-modules#7

[jwoLondon]

The location was recommended in the instructions we give for people who have EACCESS problems (see Step 2 of the litvis README and https://docs.npmjs.com/resolving-eacces-permissions-errors-when-installing-packages-globally)

npm global root is what we would expect after configuring the npm prefix:

/Users/myUsername/.npm-global/lib/node_modules

That location is part of $PATH, but I guess that's not sufficient for Atom to pick it up?

[kachkaev]

global-modules uses global-prefix, which does not seem to be calling npm root -g in any form, so is probably not counting for this edge case. Perhaps, we could start with asking for help in jonschlinkert/global-modules#7?

Jo, could you please elaborate on your use case there? I'm off for today.

[jwoLondon]

I'm closing this issue as the substantial issue of running markdown-preview-enhanced-with-litvis with latest Atom and mume has been fixed (thanks Alex!). I'll open a separate issue on prettier-plugin-elm not being detected when npm globals are in a non-standard location.

[kachkaev]

A fix for the VSCode extension has been made in gicentre/vscode-markdown-preview-enhanced-with-litvis#2 and released as 0.12.0.