w3c / scribejs Goto Github PK

The BrowserView directory has a staticly hostable UX for building minutes output from IRC logs, but we can't host out of that directory via GitHub Pages. Consequently, we have three options:

1. we can move the UX to the root folder (on master)
2. a dedicated BrowserView contents only branch (which is a pain to maintain)
3. or rename BrowserView to docs--which we can configure to host out of

My preference would be option 3, as its the simplest to setup.

@iherman let me know your thoughts, and I can send an appropriate PR, and then you can click the things in Settings. 😄

Cheers!
🎩

Nothing of interest here...

Currently the files are a mix of tabs and spaces--which means things don't always line up across different peoples tab preferences.

Would you be open to a PR that changes the whitespace to the (pretty typical for JS) 2 space characters per indentation level? See https://github.com/airbnb/javascript#whitespace for an example.

Additionally, I'd be happy to setup an .eslintrc and .editorconfig file to help keep things consistent going forward.

Your call, though. 😄

We're getting a security alert on w3c/json-ld-wg, and probably others, apparently due to a dependency on "marked" from scribejs. I presume corrective action is required in any repo that has scribejs in its package-lock.json, but it would seemly start with this repo.

Recommendation is to change dependency to "marked": ">=4.0.10", but that may have some implications on the code.

@iherman the [Configuration files](id:conf) style fragment identifier format doesn't seem to be supported by GitHub Flavored Markdown (which doesn't seem to have this feature at all...sadly) nor by Kramdown (which uses the {: #identifier} style).

Are you OK if I remove it? It appears in both the output and the README.md.

• noindex
• nofollow
• Dodge crawlers
• CAPTCHA?

Explore existing npm packages: https://www.npmjs.com/search?q=cgi.

I added JSON-LD island/data-block output support to the JSON-LD WG's home page:
w3c/json-ld-wg@8194de6#diff-2c19d9859b055d0302043d0fa2833e3f

I'd love it if we could generate some JSON-LD and add that to the Jekyll preamble for the minutes we generate ever week!

The idea is to provide more meaningful data, so @azaroth42 (and others) can write robots to figure out who hasn't scribbed recently, etc. 😁

I plan to submit a PR, but thought opening an issue for this would be best organizationally. 😃

Hi,

it seems you have accidentally added fs but this is not a package on npmjs, fs is an internal NodeJS module.

https://github.com/w3c/scribejs/blob/master/package.json#L41

See https://nodejs.org/api/fs.html

You might want to remove it using npm uninstall fs.

A comprehensive test suite would be ideal, of course.

But for now, we can make do with the simplest test: feed scribejs a minimal, fixed IRC log, and check that there's an output and that the output contains certain expected strings.

Test it both as a CLI tool and as a CGI script, if feasible.

That'd allow us to use Travis CI and have it running this test automatically for each new commit or PR, which is useful to quickly identify critical bugs, of the kind that completely break the tool.

Command line has this. BrowserView UX does not.

Idea came from #64 (comment) fwiw.

Perhaps http.get() or http.request() suffice?

Documentation says that that's a list of files to be included, but npm publish includes all files in the current dir, anyway (unless explicitly excluded).

So, what's the point of that list? It has to be manually maintained, eg updated every time a file is added/removed/renamed…

See #24.

eg, in HTTP params

So that credentials aren't commited to GH.

There are some features used in preset.js that may create problems with clients that do not understand those.

It's possible, though very "geeky", to setup a personal access token and use that with JS to make changes to GitHub repos. It would be handy if there's interest/need to provide more than copy/paste "API" for getting content onto GitHub.

Copy/paste is far more widely supported, though. 😉

Idea presented in #64 (comment) fwiw.