noseglid / atom-build

:hammer: Build your project directly from the Atom editor
https://atom.io/packages/build
MIT License
248 stars 97 forks source link

Allow consumeBuilder to accept arrays #450

Closed Gawdl3y closed 8 years ago

Gawdl3y commented 8 years ago

This adds the capability for a single package to provide multiple build providers.

noseglid commented 8 years ago

Hmm.. do you have an example of an integration which provides multiple providers? Wouldn't it make more sense to have separate builder providers instead? There's no limit to the amount of build targets a provider may give.

Gawdl3y commented 8 years ago

Mostly for reasonable separation of logic and cleanliness, and partially for #451. Take my build-papyrus package as an example. Papyrus has multiple formats it can be built to: assembly (.pas), and a fully-compiled form (.pex). Currently, my package only supports full compilation, but I'd like it to support assembly/disassembly as well. I wouldn't want to shove the assembly/disassembly-related logic into the existing build provider, as they would work rather differently from each other. I'd end up with one big, convoluted mess of code.

noseglid commented 8 years ago

I don't get it. Aren't you arguing against your point? Why not create a completely separate build provider for the assembly/disassembly functionality?

Gawdl3y commented 8 years ago

build-papyrus encompasses all Papyrus-related building, not just script compilation. If I were to separate each component into separate packages, that'd be duplicating a ton of shared code between packages (config loading, game definitions, package settings, etc). It'd also be less user-friendly, which is an important aspect to me since there are loads of brand new scripters/devs coming into the scene that may not have any prior experience (I wrote and am continuously updating a guide for using Atom for Papyrus). My goal is to reach feature parity with the official Sublime Text plugin.

noseglid commented 8 years ago

I see the appeal. I think it may be beneficial to publish an npm package for the shared code, but if you think it makes more sense to have it in the same atom plugin (that have multiple providers) I'm okay with merging this. It doesn't add much complexity.