Add ability to use atom-shell-starter as a dependency

[benogle]

Forking this project and mixing in your app-specific code in is a pretty unfortunate way to make an atom-shell app. There are consistent improvements to this project, which these forked apps cannot take advantage of without pain.

I envision a world where an app author only need to specify the domain specific bits of code. A world where the window maintaining, menu handling, building, packaging, compiling, caching, deduping, installing, etc are taken care of by an app container. And a world where apm is not necessary for non-atom apps. My vision is a utility like rails. This utility takes your minimal, domain-specific source code, and makes an atom-shell app.

• https://github.com/atom/husk-sample contains the source
• https://github.com/atom/husk-cli runs the script/* commands with the correct command line parameters

First link this behemoth

cd atom-shell-starter
git checkout bo-experiment
npm link

Then you can run the sample

cd ..
git clone git@github.com:atom/husk-sample.git
cd husk-sample
npm link atom-shell-starter
npm install
husk build
husk run -d

Or run the tests

husk run -t

TODO

• Load source code from external app
• Build app with external app code
• Make sure dev mode works
• Make specs work
• Get coffee caching working with external source
• Get menus loading from sample
• Come up with some kind of stylesheet loader, and load in an app's styles/ folder

That should be sufficient to get this to useful mergeability, or MMP (minimum mergeable product). There are several other things we could do, but they can be done in other PRs.

• Write husk install to pass the correct headers to npm/gyp, and remove the apm dependency
• Remove the ability to fork and build without an external app. This would clean up the build process, and initial run process quite a bit

[anaisbetts]

Hm - while I definitely like your Vision Of The Future, I think it's somewhat premature at the moment. This effectively turns atom-shell-starter / Husk from a template into a Framework, which is both Good (people get the benefits of upstream changes), but also comes at a pretty significant cost - people are now discouraged from changing any of the code in this repo because now they'll be Off The Reservation and into the custom npm module game / private registries / etc etc.

One of the goals of atom-shell-starter is to be Production Ready - i.e. it's not an example, you should be able to build Full Apps with it. Right now, the likelihood that I can build a Full App without modifying the code in atom-shell-starter in any way seems Low; there's too much going on in both the Atom Shell world and in this repo. In the future though, once Atom Shell itself as well as the code in here settles down, that will be way more of a tenable proposition in my mind.

Something in the middle?

Another approach we could try to do that is in-between the two, is build a really full-featured Yeoman generator for this repo. Yeoman is good at the concept of generating projects, but also allowing you to rerun the generator on an existing repo and it'll update all the files that don't have custom code in them, as well as getting us some of the features that rails generate has - it'd be awesome to be able to get something set up super fast, but then later run something like yo atom-shell:spec-runner then opt-into that. Especially because then people could build custom sub-generators on top of the base platform - yo atom-shell:angular-view, or yo atom-shell:enable-web-components or something.

Thoughts?

[benogle]

I think turning it into a framework encourages a behavior thats much more beneficial to everyone in the long-term. Right now, we're encouraging ad-hoc additions to your local fork.

it's not an example, you should be able to build Full Apps with it.

As a framework or a forkable thing this has the exact same capabilities. And if it's not ready for prime time, then having it as a framework will encourage people to add the things necessary to make it so, benefitting everyone past and future, rather than hacking in some garbage that they need right now.

Having this as a framework may encourage a little more thought and dicipline into what goes in. That's a good thing, though. But I dont see any PRs that have been submitted recently that should have been different if this were a framework.

Contributions are already coming in to make this more production ready. If anything, making it a framework will make it more accessible and accelerate them.

people are now discouraged from changing any of the code in this repo

I disagree. The impact is the same. This repo is for general bits useful for everyone. People are already discouraged from adding their domain specific junk, and are encouraged to add the general stuff that was useful for them.

build a really full-featured Yeoman generator for this repo

I think this is really the wrong approach. This still encourages quick hacks to add your sorta-general behavior, diverging you from master. Contributing is harder as you need to edit the generator, and generate to test, when you can just npm link a dependency. And there could be problems updating the non-edited files breaking the user's app.

I'm honestly not seeing any downside to making this a framework. But the upside is great:

• Will make husk "production ready" faster by encouraging additions to the framework rather than quick hacks to the local fork.
• Will remove the onus of maintenance of the boilerplate from the app author. There wont be 100 apps out there with 99 different implementations of boilerplate code.
• Easier contribution. Just npm link husk!
• Makes atom shell apps much more accessible. husk generate then edit the small amount of code in src. Simple! Yay! Happy!

The one upside of leaving it they way it is:

• You can be a cowboy hacker and cram whatever you need in.

But that upside will quickly diminish with contributions.

[thedaniel]

IMO the dream of the future should be to just add 'atom-shell' to your package.json and npm install it, and run ./node_modules/.bin/atom-shell generate (kind of what ben is saying but with a slightly different implementation detail). This fork-and-modify, or 'boostrap' style thing in this repo is a natural step toward having a proper app framework that we maintain, but I don't think it's a simple line from A to B.

I'd be much more comfortable starting with getting atom-shell to work as a dependency and slowly adding elements that support typical feature development than putting this entire repo into a generator. I don't think we should hand people a big opinionated scaffold and tell them to hack it up whether it's a fork of this repo or a yeoman generator, especially given how much atom-shell development's best practices and atom-shell itself are likely to be a moving target.

[thedaniel]

Along the lines of 'atom-shell' in npm, @maxogden and @mafintosh have done some work on this. Curious to hear about how that's been going for them.

[max-mapper]

atom-shell on npm has worked really well so far. We support linux, mac and windows and haven't had many bug reports. We currently get about 500 downloads a day.

We wrote it so we could not only use it via npm install atom-shell -g for general command-line usage, but also so that we could use it as a devDependency in applications that want to bundle their own local, non-global copies of atom-shell.

For example, if you do npm install atom-shell --save-dev and then put "scripts": {"start": "atom-shell app.js"} npm will use the version of atom-shell from devDependencies before looking in your global path for an atom-shell executable. This is an awesome feature of npm that we use a lot because it ensures that software always works and you never get the wrong version of a dependency, even if it is a command-line dependency.

The main issue we have is we don't know when atom-shell releases happen. We like to sync our npm version number with atom-shell's version number so you can do e.g. npm install atom-shell@0.18.2. I either just wait for someone to complain or when I remember I go here: https://github.com/atom/atom-shell/releases and publish a whole bunch of releases in one big sweep.

It would be super cool if someone involved with the atom-shell release process wanted to become a commiter on our atom-shell module and at least ping us when releases need to happen, or just push the releases themselves.

The release process is really simple, you just make a commit like this and then npm publish.

[thedaniel]

I'm sure we can work with you somehow -- for maximum lazy points we could set up a webhook on the github repo that just pings you when a Release is created 😎

[max-mapper]

excellent. if there's a specific person who wants to take responsibility on
the GitHub side to help us with releases, lemme know and I can add them to
our repo + to npm as an owner. I'll also write up some docs on how to
release

On Tuesday, February 24, 2015, Daniel Hengeveld notifications@github.com
wrote:

I'm sure we can work with you somehow -- for maximum lazy points we could
set up a webhook on the github repo that just pings you when a Release
https://github.com/atom/atom-shell/releases is created [image:
😎]

—
Reply to this email directly or view it on GitHub
#53 (comment)
.

Sent from my phone

[zcbenz]

We are very likely going to write a command line tool for developing Atom Shell apps during the Google Summer of Code (github/mentorships#15), and atom-shell-starter would be an important template/framework when creating apps.

The command line tool will not only be used for generating apps, it will also include the ability of installing native modules, creating distributions/installers, code signing, etc. So I think we should avoid putting the responsibility of generating apps in atom-shell-starter. And we may use husk (#52) for the command line tool instead of renaming atom-shell-starter.

[benogle]

@paulcbetts @maxogden and co have done a great job splitting this stuff out in the last few months. Closing this as no longer relevant. I've updated husk-cli to work with the current state of things. See electron-archive/husk-cli#1 for more info