npm-ization

[pmuellr]

I'm playing with a desktop version of dillinger - dillinger-the-app - and would like to have an easier way to consume the dillinger code.

Here is what I'm currently doing - from app/main.js:

require("Dillinger/app.js")

and I'm referencing this repo in my package.json as:

"Dillinger": "joemccann/dillinger",

I think we can improve on this, without changing any existing behavior.

Changes I think prolly need to be made:

• lowercase the name in package.json to dillinger; breaking change there perhaps, but I think a lower-case name in npm is preferrable to the uppercase. Don't care that much.
• create an index.js as the main package entry point, have it export a function which will require("./app") to start the server; I expect this package will be extended if needed, in the future, to be able to stop the server, query it, configure it, whatever. Just starting the server now is fine.

Unfortunately, once you've gone this far, you prolly want to go a little further:

• add a bin script so you can launch dillinger from the command-line
• add mechanisms to configure the server and plugins from the command-line, or document existing mechanism if already available.

If this sounds reasonable, I'll submit a PR.

[joemccann]

Patrick!

This is fantastic. I will say that Dillinger is currently being re-designed (UI/UX) but also getting an overhaul into a SPA using Angular. All plugins, etc. will modular in nature so npm'ng should be feasible. My suggestion is to wait until we get this bit sorted unless you feel merging the refactor to your npm'd version won't be difficult.

Thanks!

[joemccann]

@pmuellr Think we can still do this with the guide you posted above?

[pmuellr]

I suspect so.

I think I had another use case beyond creating a new desktop app project that would require the bulk of the code: making it easier to use in Heroku / CloudFoundry so I could create a super-small launcher project, with some custom config, which would then require() the bulk of the code to launch it.

That's a reasonable way to split up these "deployment" stories for Dillinger up - existing repo with the core code, and new stand-alone ones with deployment-specific bits (one for Electron, one for CloudFoundry / Heroku, etc). Or they could all go in the existing project, which would be easier. The "separate repos for deployment" story is likely premature modularization, heh.

In any case, having a programmatic way of launching the server seems like a good idea in general.

[joemccann]

Cool thanks Patrick, I'll dig in a bit.

On Mon, Sep 24, 2018 at 2:43 PM Patrick Mueller [email protected] wrote:

I suspect so.

I think I had another use case beyond creating a new desktop app project that would require the bulk of the code: making it easier to use in Heroku / CloudFoundry so I could create a super-small launcher project, with some custom config, which would then require() the bulk of the code to launch it.

That's a reasonable way to split up these "deployment" stories for Dillinger up - existing repo with the core code, and new stand-alone ones with deployment-specific bits (one for Electron, one for CloudFoundry / Heroku, etc). Or they could all go in the existing project, which would be easier. The "separate repos for deployment" story is likely premature modularization, heh.

In any case, having a programmatic way of launching the server seems like a good idea in general.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/joemccann/dillinger/issues/241#issuecomment-424135977, or mute the thread https://github.com/notifications/unsubscribe-auth/AAC8auKeySKpCiD_eWCWoJl--7byjrQ_ks5ueVIVgaJpZM4Cto4w .