How can we help you write packages?

While I agree with you, may I suggest you try the command line? Nothing can be easier than apm install my-package.

already finding myself doing that a lot lol, true.

i just think the package base has outgrown the UI, after all there’s packages with 100k+ downloads, things like autocomplete-plus (which is amazing) that have numerous package plugins, but without a real / distinct tagging system the experience of finding / installing addons for that is lackluster at best…

iono, just putting in my 2 cents here but categories + tags and a refreshed install UI could be pretty great, eh?


I have read through the docs and most of the api docs as well. I still find it a little confusing…
It seems that most examples has focus on showing small ui panels and lists.

I would love for a simple ‘hello world’-package example that

  • Opens a new texteditor-tab
  • Set a specific grammar for the editor
  • Fill the editor with some text

@vegar Now that Atom docs has its own repo (in fact, it’s now a book!), I’d recommend commenting in this issue with your ideas for package examples.


That’s great! Comment added.
Meanwhile, if someone could point me to some resources, like good existing packages with similar functionality in place, that would be even greater (at least in the short run :stuck_out_tongue_winking_eye:)

What you’re asking is pretty simple. I added the following to my

atom.commands.add 'atom-workspace',
  'custom:open-foo': -> (editor) ->
      grammar = atom.grammars.grammarForScopeName('source.gfm')

I now have an entry in the Command Palette “Custom: Open Foo” that:

  1. Opens a new editor tab
  2. Sets the grammar to Github-Flavored Markdown
  3. Sets the text of the editor tab to “foo”

I have written a helper lib atom-package-reloader, which reloads a package on file change.
(similar to the Dev Live Reload package)

I think something similar should be included in core and/or documentation.
ctrl+alt+r to update the view should be last resort for developing instead of default.

1 Like

I think it’s improving all the time (obviously) which is great. But the 2 issues that stick out for me at the moment are;

  • It’s too easy to lose authorisation (and consequently a package-name-space…) if apm publish goes wrong or the GitHub repo is deleted before apm unpublish (see #221 for example) so we are left waiting for somebody to manually delete the package namespace from a database.

  • It would be nicer if we could use a package.cson instead of package.json that also works with apm

1 Like

That would be nice for me also. Does npm support it?

That would be nice for me also.

Maybe weigh in on this issue (#464) here… although it was closed already!

Does npm support it?

The npm guys are very stubborn about not supporting it at all, but since apm is basically a wrapper around it (and clearly most of the Atom ecosystem already accesses the CSON parser) I don’t see why compiling it to package.json as an intermediate step would be so bad?

It would be nice to have every feature documented in the API.

There are a lot of features of TextEditor that I find in other packages that are not documented anywhere.

I have jumped into Package Development for a week now and after the last update I don’t seem to be able to create a Pane, getting some error with Registering Views and stuff. Imagine me with empty hands after googling for the error (and even View Registering, which I merely know to exist). The First Package Guide is very incomplete and barely has the word View on it. I am still not able to create a pane right.

Am I missing something? Any directions?

Mind sharing your code so that we can see what you’re doing? The best case scenario would be for you to open a new thread on this forum and link to your GitHub repo, then anybody who wants to help can easily download your package and see precisely what you’re seeing.

I get it, but I was using a real example for this discussion. Tough I just realized I am a few months late and this is an “old” thread.

The thread is getting close to three years old and your comment does not appear to have been directed at any previous posts here except perhaps at the original post by an admin who hasn’t logged on in nearly two years.

If you’ve spotted an insufficiency in the guide, and you share what you’re trying to do and don’t understand, that would make it easier for people here to understand where the failure is in the documentation and fix it.

It is true that we don’t cover how to do everything someone might want to do when creating a package in the Atom Flight Manual. We do publish a large number of open source packages though, a few of which do things like open panes, such as the markdown-preview package. You can find the code for opening a new pane here:

And that technique is covered in the API documentation.

I’d be interested to hear ideas on how to properly balance giving people what they need to get started and also not overwhelming them with too much information all at once.

@leedohm, this is actually the package I was scanning for help. I just realized also (trough following your link) that Panes and Panels are not the same thing. And the reason behind the error I was having was because of particular a syntax misinterpretation (my bad).

About the docs, I think it would be a very desirable piece of knowledge to be kept: a dry and simple example of creating a package which uses panels to show their stuff, if you get me.

1 Like

Hi, I am the author of CodeSideStory atom package. Here is my feedback.

What resources did you use learn how to create packages?

Flight Manual is great start. But most learning is from looking at other similar packages.

Was the documentation helpful? What was missing?

Documentation is good. But would like to see a section that explains “How to do X ?”. E.g I spend a lot of time trying to figure out how to reuse the text editor inside my UI. Have to search through threads to find out there is a mini editor already available. No documentation on it. Also if you want to add to auto complete there are so many versions and variations and even the fact that its another package. Have to go though the source to figure it out.

Was the API reference helpful? Was it helpful?

yes - API ref is to the point and most useful. The best feature is the link to the code. Don’t ever take that off.

Did you look at any code from the open source packages for help? If so, which were the most helpful.

Yes - Nuclide, atom-select-list are most useful. Also want to give a shout out to @mark_hahn and all his contribution to forum. Every time I had trouble he either asked that same question or answered himself.

What is the most important thing we could do to help you write packages?

I like to see articles targeting different UI framework developers. I did my part and created one for React-Redux. I also found the next step after you create the first package using the “Package Generator” is the hardest.

I am new to atom packages. I am building a package using ES6.
They only issue I had faced is there is no documentation for Active Text Editor View.
Most probably everything else was good enough to develop a package.

The methods for TextEditor objects are the same whether or not they’re active.