polylint -> polylint-atom

[BLamy]

I'd like to suggest moving linting code into it's own plugin known as polylint-atom.

Then make this repository an umbrella package to install all polymer tools. Including polylint, maybe rob's snippets, think future (wct-atom?). That way, as long as I have this package installed I know I always have the latest and greatest in polymer-atom tooling.

[zacharytamas]

I suggested this to Taylor yesterday as well. I have a package called atom-polymer that I was intending to make like what you describe (an umbrella collection of Polymer tooling) but consists currently of just HTML and JS snippets. I was planning things like WCT integration, linting, etc.

I think there is a combination/collaboration we can do here to simplify the landscape. Right now there's polymer-atom, atom-polymer, and Rob's snippets, which have some overlaps and could be combined.

[abdonrd]

Maybe we can have:

atom-polymer
├── linter-polymer
├── polymer-snippets
└── ...

• atom-polymer: as the oficial "umbrella".
• linter-polymer: the oficial linter, following the naming of the all Atom linters.
• polymer-snippets: the oficial snippets (by @robdodson).
• any future packages?

[robdodson]

I'm open to the idea. My only concern is having lots of cooks in the kitchen. I'm not very familiar with large atom packages... is there a similar project out there that folks know of that I could look over to see how they've structured things?

[zacharytamas]

Hey BobDod, one example that comes to mind is how Facebook does their Nuclide IDE packages: everything is separate packages you can install à la carte or you can install a giant parent package which will install everything. Their packages are a little complicated because they are doing a lot more system-level stuff (i.e. they can mount remote directories through SSH) and some quirky inter-dependencies than we probably need for Polymer. We could likely find a simpler arrangement until needs prove otherwise.

[BLamy]

When I made this suggestion, Nuclide was kind of what I had in mind. Basically, The ultimate Polymer editor. Except this one would actually work. Don't install Nuclide rob, it's a trap.

I think that over time polymer and atom will become very good friends. Especially, once they get that pesky CSP problem solved out. IDK about you guys but once that's taken care of i'm going to be writing a lot of atom plugins.

[robdodson]

That sounds good to me. @notwaldorf @garlicnation are you all on board with this idea?

[ssorallen]

@BLamy Nuclide has run into significant issues with the many-packages approach, the most apparent ones of which are the installation process and the Atom settings package that you linked (facebookarchive/nuclide#84). We are approaching a single top level Atom package at this point, which eases installation and updating (one apm install command, one 'node_modules' directory for deduping dependencies, one package in the Settings page). The nuclide-installer is not the best approach to mimic.

Other Atom packages have taken various approaches that are discussed in https://discuss.atom.io/t/depending-on-other-packages/2360/17 but no single approach has been adopted in core yet. I'd be careful of force-installing top level Atom packages because top level dependencies should really be controlled by the user (see TypeStrong/atom-typescript#711 atom-typescript force-installs its "peer" dependencies).

[tjsavage]

This sounds great to me - polymer-atom makes sense as the umbrella package, and linter-polymer as just the linter, polymer-snippets for snippets, etc.

It sounds like the question now is whether to have the polymer-atom umbrella package be a pure wrapper that force-installs each individual package, or as a single top-level atom package?

Per @ssorallen's feedback (thank you!) I think it might be best to keep as much logic as possible within modules like polylint, and then have polymer-atom as a single integrated package rather than an "installer." Downside would be we may have some duplicate code, but I think it would end up a better user experience.

[BLamy]

@tjsavage I actually don't know much about what is and isn't possible in atom but would we be able to do something like this.

polymer-atom
.
+-- .gitignore
+-- LICENSE
+-- README.md
+-- package.json
+-- polymer-atom.js
+--lib
   +-- linter-polymer (git subdependency)
   +-- atom-wct (git subdependency)
   +-- atom-* (git subdependency)

polymer-atom.js would be a thin mediator which reads the /lib folder and forwards lifecycle callbacks to all of the 'children' libs.

[ssorallen]

@BLamy That's quite similar to the approach Nuclide has started to take too. The things we've run into I can remember:

• If "polymer-atom" is the only Atom package, it will be the only one to show up in the settings page. If the sub-packages scope settings to their own names, the settings won't be visible to the user.
• If each package lists its own "dependencies", they won't be easily deduped until NPM v3+. APM is currently at v2.13.x
• The PackageManager might expose all the methods you need to make the mediator, but they aren't all documented in atom.io/docs

[opus1269]

I have written a linter-polymer for Atom. It doesn't implement all the hydrolysis options yet.

I published it once to test, but it is not currently published. You guys are welcome to take ownership if you want, as long as you list me as a contributor somewhere.

[zacharytamas]

Did anything ever happen here? It seems that polymer-atom was kind of abandoned by the team. Is there another IDE package that is first-party or at least recommended? I own the similar atom-polymer package which has fallen into a similar state of disrepair.