Project status? about assemble

[assemblebot]

@KillyMXI Thanks for the issue! If you're reporting a bug, please be sure to include:

• The version of assemble you are using.
• Your assemblefile.js (This can be in a gist)
• The commandline output. (Screenshot or gist is fine)
• What you expected to happen instead.

If your issue is related to one of the following, please open an issue there:

• grunt-assemble Issues with using assemble in grunt or the grunt-assemble library.
• handlebars-helpers Issues with using handlebars helpers from the handlebars-helpers library.

[jonschlinkert]

whoops, meant to comment. give me a sec

[jonschlinkert]

A few times @doowb and I have joked that we should create bugs in Assemble to increase issue activity. Unfortunately, a side effect of having a very stable, well-architected application is that we don't get as many bug reports, so it looks like there is less activity.

Assemble is still relevant and active, and it's used by thousands of developers. We'll be releasing a new version soon.

[KillyMXI]

I mean, you really can't find issues to tackle?

I add assemble 0.24.3 to packages and I got npm yelling at me:

found 187 vulnerabilities (10 low, 10 moderate, 166 high, 1 critical) in 10467 scanned packages

You may tell me this is fine, use yarn and don't mind it. I can only reply that this right here is your low-effort opportunity to show the project is alive.

Another point - documentation and whole infrastructure. There is a lot of stuff that were created for Grunt. I had a hard time to sort that out myself and scrape together pieces relevant to the new Assemble.
I see a lot of work to be done, and there better be a checklist of some sort to organize and bring up to date all the docs, examples and other packages...

[jonschlinkert]

I mean, you really can't find issues to tackle?

I said we don't get many bug reports that result in issue activity. That's still true.

You're describing a bug with how NPM incites panic to give them a competitive advantage over yarn. It's especially irritating because NPM's audit tool is not smart enough to differentiate between when something is a actually bug to a specific package. GitHub does this, but allowing maintainers to disable those messages when a "vulnerability" isn't really one, like when it's in a package that's only used in unit tests.

I agree with your underlying point that we should make those messages go away, but this so nuanced that it goes well outside of the scope of the point I'm making here, and what I thought was the point of your issue.

I can only reply that this right here is your low-effort opportunity to show the project is alive.

I do appreciate the spirit of your comment, and I really don't want mean to be condescending with this reply, but you seem to have very naive understanding of the cascading network effects of how small changes in a code base can ripple across the ecosystem.

Making those updates is anything but "low-effort". It is a non-stop, never-ending cycle of despair and usually, but not always, complete waste of time. I'm sure that someone will read what I'm saying as "Jon Schlinkert doesn't care about vulnerabilities". That interpretation would be false. I'm saying that:

1. This is a much more nuanced and complicated topic than I want to discuss here.
2. The vulnerability reports are unilateral and not smart enough to know how libraries are being used, and thus are crafted to describe worst case scenarios,
3. We always take care of "real" critical issues that can actually effect our users when those issues arise.

Another point - documentation and whole infrastructure. There is a lot of stuff that were created for Grunt. I had a hard time to sort that out myself and scrape together pieces relevant to the new Assemble.

Have you looked at the examples folder?

I know documentation sucks, we'll be adding more docs when we release the next version. I would love to get help with docs.

[KillyMXI]

Thank you for detailed reply. I know that npm audit doesn't give the real picture in terms of vulnerabilities. It's just the impression that the codebase gets covered with dust and cobwebs when nobody is working on it, or it got too complicated so nobody can keep it updated...

Have you looked at the examples folder?

I probably did (have to dig up some stuff to recover the details...)
It shows the basics of Assemble itself, a scaffold, not explaining where to get the meat for these bones.
One have to use variety of helpers to fill a real project with required functionality, but most of related projects in the wild were still Grunt-oriented but pointing to now incompatible Assemble. This alone created a lot of confusion.
I'd be happy to see mode on compatibility with gulp modules.

Now that I know the project is not dead, I might try and put my boilerplate project out and hopefully recall more details in the process.