Project no longer maintained?

[mattfysh]

It seems this project is no longer being maintained, with a high number of unanswered pull requests and issues raised. The last version v1.4.0 was published 8 months ago. I've reached out to the author via email a week ago and have not yet received a response

Does anyone know the process here is, anyone interested in forking this project and publishing under a new name?

[rbecheras]

Yes I planned to support a fork of the project.

I think about a complete re-factored project to provide

• a full templating system to allow to fully integrate the client-side (the web UI side) of the application in your standardized organization web application design or any custom one.
• custom extensions as configurable plugins, naturally managed by npm prefixed modules like custom (npm i grunt-*) and "contrib" (npm i grunt-contrib-*) grunt tasks modules are for example.

The aim will be to take advantage of its advanced personalization features while continuing to benefit of the project's progress and updates when it evolves.

[mattfysh]

@vernak2539 ?

[czardoz]

A lot of forks seem to be present (presumably because of PRs not being merged) https://github.com/rlidwka/sinopia/network

[RnbWd]

I tried a year ago - it's the most complex library written in express I've ever seen

[scic]

I would love if this project would be actively maintained again. Currently the missing/broken pull-through of scoped packages is beginning to become a blocker for me. Sadly this code is above my understanding so I can't help.

[RnbWd]

I've started using scoped packages in sinopia before it was officially implemented in npm - there's a configuration in yaml that enables pulling @name/package's. I haven't used sinopia since the scopes were implemented officially and npm was upgraded to 3.0 - so I'm not sure if the scopes pull from npm or just act locally - but effectively it can be used instead of npm as a private repo - I used it w/scoped variables - but not via npm.

[jdx]

I've got a npm server that's a bit different than sinopia, but a lot simpler that might be worth a look: https://github.com/dickeyxxx/elephant

We're using it in production at Heroku with great success! It's very fast!

[mima0815]

@rlidwka can you give us a short statement on the status of sinopia?

[RnbWd]

I just turned on my docker sinopia container for the first time in 6 months and it seems to work fine. Many of the problems posted here might be solvable by changing a few lines of code or simply making the config.yml work properly - which is honestly esoteric. But if it works.. it works. I consistently had a 10x speed improvement the entire time I used it hosted on a tiny docker server in the cloud - but I still haven't tried scoped variables since they were officially implemented. They worked fine last summer, but it requires the proper setup in the config

edit: scoped variables are working fine with me - but they're local to the sinopia. check out the configuration for my docker repo https://github.com/RnbWd/sinopia-docker

double edit: I'm using node 5.7.1 and npm 3.8.1 - but I can only get sinopia to run on 0.10 (it briefly worked with iojs) so my docker container - running sinopia in 0.10 - is probably more stable to use than if one were to just download sinopia 'vanilla' in a modern node context

[ChadKillingsworth]

Proxying scoped packages work just fine - you just have to set the config correctly (the default is wrong).

You need 2 asterisks:

packages:
  '**':
    # allow all users (including non-authenticated users) to read and
    # publish all packages
    #
    # you can specify usernames/groupnames (depending on your auth plugin)
    # and three keywords: "$all", "$anonymous", "$authenticated"
    access: $all

    # allow all known users to publish packages
    # (anyone can register by default, remember?)
    publish: $authenticated

    # if package is not available locally, proxy requests to 'npmjs' registry
    proxy: npmjs

[RnbWd]

I use this setting for scoped packages:

@/
# scoped
allow_publish: $authenticated

I haven't used the "**" setting, I'm jw if there's an issue the "@/" setting when proxying npm?

[ChadKillingsworth]

The matching algorithm uses the node glob library so it's the same matching rules. A single * won't match a /, but the double ** does.

*/* works just as well if you want to have a rule for just scoped packages.

[ChadKillingsworth]

I also emailed @rlidwka about a month ago and never heard back. He has near-continuous public activity on github for the past several months which leads me to believe he is purposefully ignoring this project.

A fork, name change and license change would be in order it seems. I just don't have the time right now to maintain a package like this appropriately.

[RnbWd]

I'd volunteer to give it shot - I'm maintaining the docker container that
seems to have the most downloads for this project - and I had to forked it for a minor feature so I could proxy it via ssl with minimal config. I've
read every line of the code base, so I have a mental model of its
structure. The foundation uses libraries that are not compatible with
modern nodejs. Those sections can be rewritten, the library can be
modernized, i know where it needs to change - but it's ambitious. I
attempted to modernize it a year ago, but none of that's relevant now.

I need to think this over for a few days - it's not a trivial library to
maintain.
On Sun, Mar 13, 2016 at 7:25 PM Chad Killingsworth notifications@github.com
wrote:

I also emailed @rlidwka https://github.com/rlidwka about a month ago
and never heard back. He has near-continuous public activity on github for

[cuzzinz]

It would be amazing for this project to be forked and modernized. It is by far the fastest solution even compared to local-npm and lazy_npm.

I have compared a few different solutions and sinopia is faster by 15-30%. It is very impressive.