[LRUG] resolving JS dependencies on deploy

[Sleepyfox]

It turns out that you don't really need Grunt, Gulp et. al. and
instead can do most all of the things with just npm:

http://blog.keithcirkel.co.uk/how-to-use-npm-as-a-build-tool/

Having been down this route myself I can thoroughly recommend it.

@sleepyfox
--

On 19 November 2015 at 16:13, Mark Burns <markthedeveloper at gmail.com> wrote:
>> onerous npm-derived asset preprocessing
>
> I'm curious about this statement.
> Is it that you are loathe to have to put in the groundwork now for little
> benefit or that the asset pipeline is less onerous?
>
> IMHO the tooling around the node ecosystem feels a lot more modern and
> suited to the task than the cludgy asset pipeline.
> Things like webpack, ES6, requirejs etc are fantastic for modern js
> development.
>
> Admittedly an upfront cost in tearing down everything if you only have a
> little js. But then again easier and cheaper to do well earlier on.
> On Thu, Nov 19, 2015 at 11:46 PM Tom Armitage <tom at infovore.org> wrote:
>>
>> TBH, I’m not fussed about it being gemified - it’s a single .js file,
>> really - but I liked that rails-assets exposed a Ruby packaging mechanism to
>> me, rather than wrapping a node one.
>>
>> On Thu, Nov 19, 2015 at 2:39 PM, Riccardo Cambiassi <bru at codewitch.org>
>> wrote:
>>>
>>> Hi Tom,
>>> I'm not sure it applies to your case, given your problem is with
>>> licensing, but would it make sense to fetch the said gemified library from a
>>> git(hub) clone repo?
>>>
>>>   R
>>>
>>> On Thu, Nov 19, 2015 at 2:34 PM, Tom Armitage <tom at infovore.org> wrote:
>>>>
>>>> I have a Rails project with dependencies on a single external JS library
>>>> that for reasons - primarily, licensing - I don’t want to include in my
>>>> vendored libraries.
>>>>
>>>> Currently, I’ve been referencing it via Rails-Assets
>>>> (https://github.com/rails-assets/rails-assets) which makes it available as a
>>>> gem, and thus it’s bundled by the end-user at deployment time.
>>>>
>>>> Except: Rails-Assets is down, again, and the future of the project is
>>>> feeling a tad suspect. So I’m asking for myself: what are my alternatives
>>>> here?
>>>>
>>>> I am loathe to tear out my basic usage of asset-pipeline to replace it
>>>> with some onerous npm-derived asset preprocessing (gulp, grunt, etc, etc,
>>>> etc); I also really can’t include the library within my codebase, so need to
>>>> find a way for it to be pulled down, both locally (for development) and on
>>>> deployment via Capistrano.
>>>>
>>>> Any thoughts? How do you tend to do this?
>>>>
>>>> _______________________________________________
>>>> Chat mailing list
>>>> Chat at lists.lrug.org
>>>> Archives: http://lists.lrug.org/pipermail/chat-lrug.org
>>>> Manage your subscription:
>>>> http://lists.lrug.org/options.cgi/chat-lrug.org
>>>> List info: http://lists.lrug.org/listinfo.cgi/chat-lrug.org
>>>>
>>>
>>>
>>>
>>> --
>>> Riccardo CAMBIASSI
>>> http://twitter.com/bru
>>>
>>> _______________________________________________
>>> Chat mailing list
>>> Chat at lists.lrug.org
>>> Archives: http://lists.lrug.org/pipermail/chat-lrug.org
>>> Manage your subscription: http://lists.lrug.org/options.cgi/chat-lrug.org
>>> List info: http://lists.lrug.org/listinfo.cgi/chat-lrug.org
>>>
>>
>>
>>
>> --
>> Tom Armitage
>> http://infovore.org
>> 07813 060578
>> _______________________________________________
>> Chat mailing list
>> Chat at lists.lrug.org
>> Archives: http://lists.lrug.org/pipermail/chat-lrug.org
>> Manage your subscription: http://lists.lrug.org/options.cgi/chat-lrug.org
>> List info: http://lists.lrug.org/listinfo.cgi/chat-lrug.org
>
>
> _______________________________________________
> Chat mailing list
> Chat at lists.lrug.org
> Archives: http://lists.lrug.org/pipermail/chat-lrug.org
> Manage your subscription: http://lists.lrug.org/options.cgi/chat-lrug.org
> List info: http://lists.lrug.org/listinfo.cgi/chat-lrug.org
>