Broken ide- packages due to "call.getFileName is not a function"

[mjrodgers]

Thanks in advance for your bug report!

• Have you reproduced issue in safe mode?
• Have you used the debugging guide to try to resolve the issue?
• Have you checked our FAQs to make sure your question isn't answered there?
• Does your issue already exist?
• Have you checked you are on the latest release of Pulsar?

What happened?

Several important packages are currently broken in Pulsar (as well as the most recent Atom releases), this seems to be an issue related to the bump from Electron 9 to newer versions.

I'm personally experiencing the issue with ide-python, but there are reports of similar issues with atom-ide-javascript and atom-ide-debugger. These packages all give the message
"Failed to activate the X package
call.getFIleName is not a function."

I have this issue in the latest issue of Pulsar, I do not have the issue with Atom 1.60.0 although it does occur in all versions after this. I'm using macOS 12.6.1 but there are also reports of this issue happening in Windows and Linux versions.

Related issues
[(https://github.com/atom/atom/issues/25398)]
[https://github.com/atom-community/ide-python/issues/483]

Which OS does this happen on?

🍎 macOS

OS details

12.6.1

Which CPU architecture are you running this on?

64-bit(x86_64)

What steps are needed to reproduce this?

Have one of the following packages installed:

• ide-python
• atom-ide-javascript
• atom-ide-debugger

the error appears on opening Pulsar and again on opening a new window.

Additional Information:

No response

[confused-Techie]

Really quickly I just want to confirm that this is version Pulsar-1.63.2022120423. There was an issue earlier today causing an error that seems similar to what you are describing that I reverted a few hours ago.

But otherwise, since you're reporting this also happens on Atom's latest release it sounds like this isn't the case. I appreciate the bug report and we will see what we can do, thanks!

[mjrodgers]

I'm running Pulsar-1.63.2022120405, that I updated.... maybe 36 hours ago? I will update again. But yeah, these problems seem to have appeared back at the first Atom 1.61 beta versions and have been carried over to Pulsar from that.

[confused-Techie]

I'm running Pulsar-1.63.2022120405, that I updated.... maybe 36 hours ago? I will update again. But yeah, these problems seem to have appeared back at the first Atom 1.61 beta versions and have been carried over to Pulsar from that.

Yeah that's the most likely cause is we inherited it our made the same Electron Bump as they did. But yeah feel free and let me know if the behavior is any different. Not to confident but won't hurt to find out

[DeeDeeG]

It was indeed a known issue in the Electron 11 upgrade, assuming this isn't a misleadingly similar issue. See the comments below from the Electron 11 upgrade PR discussion, for context and discussion at the time.

• Electron upgrade 11.4.7 atom/atom#22687 (comment)
• Electron upgrade 11.4.7 atom/atom#22687 (comment)
• Electron upgrade 11.4.7 atom/atom#22687 (comment)

This might have also been what broke Hydrogen, I forgot about that. It's been a bit since Electron 11 happened on Atom master branch.

[shr00mie]

not sure how relevant this might be, but I had to lock Hydrogen @ v2.16.2 back in the Atom days, and that version of Hydrogen worked perfectly through the last release, at least on Windows.

having a weird issue with Pulsar + Hydrogen on OSX at the moment...

if i try to run and go to next via Shift+Enter, or run via CMD+Enter, Pulsar throws a Uncaught TypeError: editor.languageMode.rowRangeForCodeFoldAtBufferRow is not a function
/User/[username]/.pulsar/packages/Hydrogen.dist.utils.js:177

but...if i highlight the same row, and then go to Packages > Hydrogen > Run...it works just fine.

keymapping issue?

sort of makes Hydrogen mildly unusable if you gotta use the dropdowns every time to run code.

I'd think this was a Hydrogen issue if it wasn't for the dropdown method working just fine.

oh. also. you guys are fucking rockstars for picking up the baton. thank you so much. <3

[LRydin]

not sure how relevant this might be, but I had to lock Hydrogen @ v2.16.2 back in the Atom days, and that version of Hydrogen worked perfectly through the last release, at least on Windows.

having a weird issue with Pulsar + Hydrogen on OSX at the moment...

if i try to run and go to next via Shift+Enter, or run via CMD+Enter, Pulsar throws a Uncaught TypeError: editor.languageMode.rowRangeForCodeFoldAtBufferRow is not a function /User/[username]/.pulsar/packages/Hydrogen.dist.utils.js:177

but...if i highlight the same row, and then go to Packages > Hydrogen > Run...it works just fine.

keymapping issue?

sort of makes Hydrogen mildly unusable if you gotta use the dropdowns every time to run code.

I'd think this was a Hydrogen issue if it wasn't for the dropdown method working just fine.

oh. also. you guys are fucking rockstars for picking up the baton. thank you so much. <3

I opened an issue #319 since I am facing the same issue :)

[mjrodgers]

I'd love to help get this fixed, I'm not really knowledgeable about Javascript/node.js development, but I still know my way around some code.

The issue seems to be in the following packages:

• ide-python
• atom-ide-javascript
• atom-ide-debugger
• atom-ide-console

and in each case is caused by a line in nuclide-commons-ui/Dropdown.js. Now in trying to track this down, what these four packages have in common is that they all require @atom-community/nuclide-commons-ui version 0.8.2 or 0.8.3 in pnpm-lock.yaml. I have no idea where this code gets actually pulled from, but it is very different from the version of nuclide-commons-ui/Dropdown.js that is found in the atom-ide-base repo. Can someone help me track down what's actually going on here?

(for the record, the offending line in Dropdown.js is (0, _assert.default)(_electronRemote.default != null);)

[confused-Techie]

@mjrodgers
So essentially, what's going on here:

You are correct, nearly all of the ide- packages have a shared dependency @atom-ide-community/nuclide-debugger-common of 0.8.3 or 0.8.2. That package then relies on @atom-ide-community/nuclide-commons-ui which seems to have a matching version (because as I'm sure you've seen, all of these packages are in a monorepo).

But from there what's happening is the code of Dropdown.js doesn't match what's installed is because it's TypeScript.

TypeScript seemingly can be used within a JavaScript file, then compiled at a later time to make it totally valid JavaScript. And my assumption is that during the Publish process (which puts these files onto NPM) they are being processed by TypeScript to be turned into valid JS, and that could be the source of the problem or it could be something else. Potentially the version of TypeScript is older, and generating invalid JavaScript, but we would have a hard time confirming this. The other possible issue I'll touch on more below.

Now unfortunately I can't confirm this theory, since the maintainers that wrote the ide- packages decided to not have the publish process baked into the package, nor list TypeScript as a devDependency so I can only guess that this is the issue.

But from my best guess the offending line is actually invariant(remote != null); which is line #26 of Dropdown.js. I'm assuming this because of the comment right below that line // For backwards compat, we have to do some conversion here. is what's listed alongside line 45 from the offending code. While at the same time, right above this line remote is defined as @atom-ide-community/nuclide-commons/electron-remote and invariant is defined as assert.

Which if this is actually the offending line it could have something to do with assert actually being the offending library, but something would still have to process this file after the fact to change it's output, so it must also be something in their build pipeline.

So to anyone wanting to fix this, it'd be looking at @atom-ide-community/nuclide-commons-ui and resolving either an outdated TypeScript issue, or an issue with the assert library, or some other mystery build time processing that happens that we can't know of. But the tedious part is even after this is fixed, the issue itself isn't fixed. You'd need to then ensure that nuclide-debugger-common is updated to use that forked or newer version of nuclide-commons-ui (Which also means publishing the ui package to NPM, or monorepo), but even then once nuclide-debugger-common is updated with this newer package version, you then have to update every single ide package to now rely on your newer version. So it's a bit of a cascade of updates once you finally find the fix.

---

Now if you're at all curious, the likely reasons into why this hasn't been totally fixed just yet, and why it potentially broke.

As for why it broke, that's pretty easy, when we bumped NodeJS/Electron versions, the rules of JavaScript changed a bit, onto what was allowed JavaScript, such as things like exec no longer being secure, and being removed, or things like disallowing JavaScript Sloppy mode totally, so this particular issue likely falls into one of these.

As for why it likely hasn't been fixed. Thing is, now matter how much we got confused in the beginning, Pulsar is not Atom-Community. Nobody that works on the Pulsar project ever created any of the Atom-Community packages. So none of us know this build process, or the codebase itself, nor have access to actually fix it as it stands. Additionally, many team members disagree with much of the philosophy of how those packages were built (such as auto installing additional packages a user never asked for, or this circular self reliance they use), and at least for myself, it's never why I've dived to deep into the codebase.

But onto an important bit into what I've described, nobody here has access to these packages as they stand, and the few that do, we have previously submitted bug reports to get things to work, only to have the fixed versions never actually published to Pulsar, so that still the issue isn't fixed for Pulsar users, which makes the idea of these being totally fixed seem impossible. As even if we fork them, and do all the maintenance to fix them the broken versions will still be listed and installed.

---

Personally, what I'd really want to see as a solution here, is essentially a fork of these packages that can do significant work into repairing the issues these packages display, that if ever made, I would then be more than happy to finally list these packages as broken, and recommend installation of the fork instead.

---

So sorry that was a lot, but I've looked at this code base so many times, and debating what might be the easiest way to fix it, and since you've asked for what's going on here, thought I'd give you a full explaination.

[mjrodgers]

@confused-Techie
Thank you so much! I can usually figure out what's going on even if I don't know the language well. I was truly baffled by not being able to track down where this code was being pulled from.

I think I have tracked down the real issue (although I see now the issues with this actually getting pushed through...). The call to assert is giving the error, but it's really the ARGUMENT that is the problem, namely we have this line:

invariant(remote != null)

that I guess actually calls assert, but this remote is pulled from `@atom-ide-community/nuclide-commons/electron-remote', which includes just two simple lines:

import {remote} from 'electron';
module.exports = remote;

this gets transpiled "correctly" to javascript var _electron = require("electron");. But this should now be (some variant of) require('@electron/remote').

I think this simple change could get everything working again in Pulsar. However, since the current version of Atom is running Electron 9, this would be a breaking change for anyone who installed atom-ide-base through the GitHub link and so is still receiving updates there. This seems like an easy fix though, I'm assuming we can just put a conditional and require the appropriate module based on the Electron version being >= 10 or not?

[DeeDeeG]

This seems like an easy fix though, I'm assuming we can just put a conditional and require the appropriate module based on the Electron version being >= 10 or not?

I do think dynamic require()s can be done conditionally, hopefully this would work to use electron for older Electron and @electron/remote for newer Electron? Great idea if that can prove to work.

[pbsds]

Any progress?

[savetheclocktower]

My guess is that this hasn't been a big priority since it's a bug in someone else's code, and the bug is also present in the latest version of Atom.

I think @mjrodgers is right with this comment, so a user can hotfix this by either (a) finding this file in their package's node_modules and commenting out the offending line, or (b) replacing it with @mjrodgers's suggested fix somehow.

To be able to “fix” this from where we're standing, we'd have to fork all the IDE-related packages that hit this code path and release updated versions. That's not the sort of thing I'm eager to do, but I recognize we might have to do it eventually. My goal is to eventually divest us of all the Nuclide dependencies, or at least be able to offer less Nuclide-y versions of the same things (see pulsar-outline-view).

I am very grateful for the atom-languageclient library, all the work done on the ide-* packages, and the creation of services for each IDE task that make it straightforward to implement UI packages for those tasks. I am less grateful for the specific decisions that Nuclide made to transform Atom into a monolithic, Eclipse-like blob.

[mjrodgers]

Just a note, I have forked and published an updated pulsar-ide-python package that can be installed from the package repository within Pulsar, and has this bug fixed. I've had some helpful bug reports already, and have it working with I believe all of the ide-* backend packages. And I have heard of people having luck using ide-typescript as a replacement for ide-javascript (I think it works with javascript?).

[savetheclocktower]

Luckily, even though PPM is currently having problems, it should still be possible to install packages from within Pulsar settings by going to the Install tab and searching for pulsar-ide-python.