Where to begin with contributing?


#1

Hey everyone. I’ve been lurking around here for a few weeks. I created a package, mark-ring (mostly by cannibalizing code from another package), and I’ve been messing around with the “hackable” features of Atom.

So far, I’m really impressed. I found it pretty easy to dive right in, but now I’m at a stopping point. I really want to start working on things people want, but I’m finding out that getting the information I’d like is a little overwhelming. The API documentation is okay for what’s there, but the undocumented features of even the little things are really making this much more difficult.

Here are a few examples:

  • Take apm for instance. I tried publishing a new version of my package earlier, but I messed up the README after I’d moved to version 2.0.0. I had no idea how to add and publish the small change to stay at 2.0.0.
  • What is dev-mode? I’ve tried to figure it out. I spent about an hour yesterday trying to figure out what it was exactly, but I didn’t come up with a definitive answer. What does it change, other than loading packages in the developer folder? That wasn’t even documented.
  • How does the View system work?

Pretty much every critique laid out in this thread is still valid. I know the API freeze is on, and that getting the documentation up to snuff is on the list now, but it’s been 7-ish months now. The biggest quote from that thread, to me, is:

I found the documentation to be enough to simply set up a package in the first place, but no help in building one. The API reference has good explanations for some classes, but not for others.

So my question to you is, do you have any simple ideas for things that I could use to get acquainted with the architecture more quickly (or in smaller chunks)?

I don’t come from a web-dev background either, so a little information about how much node.js, jQuery, etc. I’d need to know to be effective would be much appreciated as well.

If I came off as confrontational, please don’t take my comments the wrong way. I really do find hacking away to be very enjoyable, and I look forward to Atom’s future. Even with my limited knowledge, I’ve produced something which I never did with Vim or Emacs.


#2

I’m going to address these things kind of willy-nilly … so bear with me …

To start with, Atom hasn’t reached 1.0 yet. Since I’ve started working with Atom in late February, it has had two pretty significant UI overhauls and is now starting on a third. The configuration system has grown by leaps and bounds. Heck we’ve been through three different versions of Chromium in as many months! Atom is moving at a fast pace because there are a bunch of things that have to be ironed out before we settle down with the 1.0 version of the API. Because Atom is changing so much and so rapidly, getting and keeping things documented at a detailed level just isn’t in the cards right now. To that, all I have to suggest is people here are very willing to help … so just ask!

This topic has some of the differences documented (though I don’t think the window size thing is there anymore):

The easy way to publish a tiny change like that is to just let apm manage the version number for you. Commit the change to the README, push it and then do: apm publish patch. Yes, you will end up with v2.0.1 … but, personally, that is more in keeping with the semver system anyway.

I think this topic was a good set of ideas for how people got to where they are with the API, even in the rapidly changing scene:

If you want suggestions on things to work on that could benefit the community, there is a list of ideas here too:

Welcome to the community!


#3

Thank you for taking the time to list all that for me. I’ve stumbled across the must have packages thread before. That’s where I got the idea for the package I already wrote. I think I may try to tackle AlignTab next.

I hadn’t seen the one about learning the API though! This one will be extremely valuable.

I guess this is the biggest thing I needed to be reminded of. I’m used to working with software that’s at least matured a bit. Some of the things about Atom haven’t even been decided yet (I’ve seen the debate about the autocomplete features going on recently). It’s exciting to be able to have an impact and fill need while not necessarily reinventing the wheel, but it comes with drawbacks (deprecated APIs, and less documentation).

Anyway, I really appreciate it @leedohm.


#4

The whole point of dev-mode is to load packages from the dev folder. Now why is this useful, you ask? Well, suppose you’re working on a package and you messed it up and now you can’t use Atom anymore. What you can do? You can fix the bug using vim and then try again. But of course, that’s not the right spirit :slight_smile: So dev-mode exists so that you can use Atom to fix bugs in Atom packages even if that package bug causes Atom to become nonfunctional.

There are other ways to do it, but dev mode seems convenient.


#6

You might be thinking of Safe Mode. Safe Mode, launched with atom --safe, doesn’t load anything but default-installed packages.

Dev Mode, launched with atom --dev, loads everything that is normally loaded, and loads all packages in ~/.atom/dev/packages. Also packages in ~/.atom/dev/packages take precedence over both default-installed packages and user-installed packages (in ~/.atom/packages).

Also useful to developers, you can author a package anywhere in your file system and then link it to the right place by using one of the following commands:

  • apm link — Links the package directory to ~/.atom/packages/package-name
  • apm link --dev — Links the package directory to ~/.atom/dev/packages/package-name

I like to store all my projects in ~/Source/project-name, so I often use the apm link command to maintain links to the right places.


#7

Does the generate package command automatically link to ~/.atom/dev/packages/?


#8

@JHonaker, by default it automatically links to ~/.atom/packages, but you can set it to link to the development packages folder here: