Impact of Nuclide extension being removed?


#1

With reference to the recent blog entry: https://blog.atom.io/2018/12/12/facebook-retires-nuclide-extension.html, I was wondering if this would impact any of the other “atom-*” IDE packages, or are they separate entities?


#2

I was also asking me that question yesterday evening. AFAIK and figured out the Atom-IDE / Nuclide is an umbrella project / collection of various things.

First of all there is the atom-languageclient npm module that provides the integration of the Language Server Protocol to Atom. This module is already in the Github/atom organization (https://github.com/atom/atom-languageclient), and I would assume that it will be maintained and developed further by the Atom Core ppl. (??).

Then there are a couple of additional views and panels such as an Outline, a Debugger, Diagnostics and an integrated terminal view (https://github.com/facebookarchive/atom-ide-ui/tree/master/modules/atom-ide-ui/pkg). Some of these could eventually be replaced with an Atom package such as Terminal Pane etc.

Additional features such as Code Refactoring (via Language Server Protocol) as well as Debugger Integration (via Debug Adapter Protocol) might have to be rewritten (not sure if every feature is/was already in)… so at least my understanding (https://langserver.org/, https://microsoft.github.io/debug-adapter-protocol/).


#3

Actually I would like the idea to break up the monolithic Atom-IDE package into smaller components that can be mixed up as needed…


#4

It seems that the atom team will not take it under their umbrella any time soon - see https://github.com/atom/atom/issues/18584

Maybe some community members could use the already existing https://github.com/atom-community/ organization on github to move/create the atom-ide-ui repo or create repos for each individually.


With Facebook Announcing Its Retirement of the Open Source Nuclide, What Will Happen?
#5

I think using the existing GitHub organization makes sense for these imports where nobody’s really going to have ownership (if it goes right), and it would make it easier for users to follow the suite of modules through the migration to their new, more communal home. @Wliu and @leedohm might be able to provide more insight.


#6

Hmmm a lot of the repos in the Atom-Community Team are either deprecated or not any longer maintained as well. So not sure how serious these guys are still on maintaining Atom packages.

As mentioned above I think a first step would be to collect information on what is in Atom IDE, what might be substituted with already existing and maintained packages (terminal, linter and such), what can be taken over as is (langserver integration) and what has to be renewed / rewritten from scratch (debugger support)…

I would like to start looking into this. If someone would like to join or can help set this up I would be glad to hear from you…


#7

From the original mission statement of Atom IDE

Improved language integration

Get smarter context-aware auto-completion , code navigation features such as an outline view, go to definition and find all references. As well as hover-to-reveal information, diagnostics (errors and warnings) and document formatting .

I would suggest to have at least the following topics covered:

  • Language Server integration via atom-languageclient; offering services and views for auto-completion, hover-to-reveal information as well as refactoring features
  • Code Navigation via tree-sitter parser integration (if possible); offering services and views for outline view, goto definition and find all references
  • Diagnostics via linter integration; offering errors and warnings for a wide range of linter providers already
  • document formatting via prettier integration (and its various plugins)
  • integrated terminal via terminal-tab and terminal-tab-service
  • Debugger integration has to be refactored to make use of the Debug Adapter Protocol and offer debugging related services and views (would be the most complicated part imho).

#8

This is a major disappointment to me. I also hope GH reconsiders taking over this repo, it plays a massive role in my workflow with Rust and I’m sure it plays a massive role in the workflow of tons of others. Without it, I’m stuck going back go VS Code again (not my preferred option). I really believe this needs to be a core package; letting it slip and become abandonware sets Atom back so much in terms of functionality.


#9

Just for my own clarification: do you mean that we could (should?) replace the Atom IDE package with a number of other packages, some of which (like linter and prettier) already exist?


#10

Yes that would be my proposal. So instead of having a big package hosting a couple of related things I would rather break it down into smaller ones following the guidelines of *nix (a small tool for every task). So it would be possible to eventually re-use already existing packages, easier maintain and evolve new ones as well as cherry pick what’s really needed…


#11

Interesting fact: if you take a look at a couple of ide- packages on GitHub (e.g. https://github.com/atom/ide-typescript/blob/master/package.json#L63-L128) you will notice that they don’t reference atom-ide-ui directly (so they don’t have a hard dependency on it).

Instead they are consuming services such as linter-indie, console, and datatip among others. Whereas linter-indie can be provided by the default linter packages as well, some of the others have to be separated out from the atom-ide-ui package and made available via dedicated apm packages (most importantly console and datatip from my initial observation).


#12

First test with a minimal set of Atom extensions (check https://github.com/appelgriebsch/dotFiles/blob/master/atom/apm.packages) shows that Language Server integration with Intelli-Sense is working out-of-the box with the build-in autocomplete-provider:

build-in nodejs type:

custom-type with typings definition:

What is not working is the integration with the linter/linter-ui-default. At first sight it looks like the linter-service API has been updated from v1 to v2 for the language server integration and the ‘old’ linter service only offers v1…

Further findings… Atom-IDE UI is using FlowType heavily. To cleanup and separate the items I would rather go with plain ES6/7 and for any type exposed to the outside provide a TypeScript compatible typings definition. So users will have type checks when using the services, but internally the package code will be quite clean.

As already mentioned above the whole Atom-IDE UI package is an umbrella project for a couple of things, and the Facebook engineers provided their own PackageLoader as part of the package. From my point of view this will no longer be necessary if the whole thing will be split up into its unique parts and made available as dedicated (eventually namespaced) packages.


#13

I’m very onboard with having separate packages. It’s great to see you’ve got things working with the built in autocomplete ui. The next thing I’d love to see is the tooltips. I’d like to help out however I can. Also +1 to leaving out FlowType


#14

@appelgriebsch, are you planning to have all the same functionality as the original atom-ide-ui, just with separate packages? Will your packages still provide the same ui support? Will this break the current language-ide packages?


#15

To me it sounds like this is the right direction :+1:
In my opinion it should not affect the existing IDE packages because they are only loosely coupled via APIs.
@appelgriebsch If you need help, pls tell me, I would really like to help :slight_smile:


#16

I’m not a particularly good (or consistent) developer, but I know Atom really well and I write highly literate, clean code when I do, so I feel that I am well-positioned to be a contributor to things that already exist (I also don’t want these packages to be dustbinned; even though I’m not the heaviest user of them, I do appreciate having the features and would miss them). So count me in for periodic projects to answer a specific issue on something that I can handle on the pure JS end, like working with Atom’s UI or the Node API. I don’t have any one module that I’m most comfortable with or concerned about, but maybe over my next weekend period I could take some time to look deeply at the various modules and any open issues they have to see if there are any challenges that I feel down for tackling.


#17

Hey, thanks for your feedbacks. Anyone experience what’s the best practice for Atom packages: split services and UI into dedicated packages (such as linter and linter-ui), or have them together in one package (such as autocomplete-plus)?


#18

It would depend on whether the different parts are useful separately or if splitting them would confuse users. Atom packages are able to provide consumable services (tool-bar exists as a service without its own interface; tree-view has a service that another package can use to make its own tree view, and it has its own UI) and I think the tree-view model is appropriate here. A linter maintained by the community that continues the implementation of the current linting standards could, with very little extra work, also provide all the error messages in nicely formatted JSON to any package that wanted to implement its own UI.


#19

Very happy to hear that you are available to at least look at these packages @DamnedScholar, as I highly respect you, your knowledge for Atom, the languages Atom is written in. I’m a heavy coder, but I barely touch JS or CS; only wrote a few very minimal and simple packages for Atom and I needed help for each.

I’m really hoping that whatever happens with these packages, that they continue to have the same functionality (ability to format code/format on save, debug, in-line error and warning messages, etc.) and don’t force language-IDE developers to change their packages. I’m just hoping that nothing too big changes. I’m happy to hear you don’t want these to leave the Atom ecosystem; I waited years for Atom to have these features and only just recently adopted them into my workflow and I really don’t want to lose them. I wish I could help maintain them.


#20

I agree with @DamnedScholar