profile
viewpoint

iarna/aproba 116

A ridiculously light-weight function argument validator

entropic-dev/ds 53

entropy delta: the entropic client

iarna/abraxas 50

A streaming gearman client / worker / server (as you choose)

iarna/App-Every 34

Easily create and queue cronjobs from the command line

entropic-dev/dstopic 19

:crab::package: a backing api for ds, written in rust :package::crab:

iarna/assetize 16

proof-of-concept

iarna/babel-autonode 8

Automatically and transparently use as little babel as possible with whatever version of node is in use.

ceejbot/putter 5

fanfic archive that doesn't suck

entropic-dev/terraform-aws-entropic 3

terraform module for provisioning entropic

pull request commentiarna/cli

fix(package): fix vulnerable deps

This is why I loathe how security reporting has gone, but unfortunately I don't have a better option. Correct me if I'm wrong, but this is a DDOS vector? Where an attacker could construct a set of command line arguments that would result in the app leaking memory? Which for a command line tool is a deeply uninteresting sort of problem. Instead, everything gets painted with the brush of long running web apps, who consume data not supplied by the person using the app.

I'm a bit surprised that audit would be pointing at this though -- the updated versions of the transitive dependencies are all compatible -- you should be able to just npm audit fix to grab those and leave this module untouched (or use the specific update command from the report). Although... yarn, well, I don't know if it has any facility to individually update a transitive dependency?

Anyway, this PR looks good, I'll bring it in.

antongolub

comment created time in a month

issue commentJamieMason/shrinkpack

Add support for npm5

I've got no idea what npm's plans are these days, but they do have an active rfc process going, and it may be useful to bring this up there again.

JamieMason

comment created time in 2 months

issue commentiarna/iarna-toml

How can i stringify toml comment?

Probably both, certainly if it can do the first, then the second should be straightforward.

Yansongsongsong

comment created time in 2 months

Pull request review commentiarna/iarna-toml

Add ESM Support.

 {   "name": "@iarna/toml",   "version": "3.0.0",-  "main": "toml.js",+  "main": "./toml.js",+  "exports": {+    ".": [+      {+        "require": "./toml.js",+        "import": "./toml-esm.mjs"+      },+      "./toml.js"+    ],+    "./esm": "./toml-esm.mjs"+  },

The rule for backwards compat is just that we shouldn't needlessly break existing users of the library. Introducing new, optional, features, like esm support, need not support all the way back.

LJNeon

comment created time in 2 months

issue commentiarna/iarna-toml

Outdated Node.js version support

If you could phrase this as a PR? =D

As far as older versions go: I'm not about supporting lazy devs, I'm about supporting overworked ops teams. The reality is that all of security is constant cost/benefit calculations, and the risk level of a given vulnerability is going to vary a lot depending on the specifics of the situation. Folks tend to think in terms of Node backing up websites, but I know of a number of very large Node installations that are not web based at all.

LJNeon

comment created time in 3 months

issue commentiarna/iarna-toml

stringify adds underscore as integer decimal separator

I'm honestly surprised that you think it would be more editable/readable without separators. That said, using thousands separators versus ten thousand separators betrays my biases.

I'm hesitant to add configuration to the stringifier, but I have to admit that this is probably the place for it.

zanona

comment created time in 3 months

issue commentiarna/iarna-toml

Outdated Node.js version support

Unpopular opinion: Because a version of node is unmaintained doesn't mean modules shouldn't support them.

Second unpopular opinion: I avoid ESM whenever possible.

That said:

11 and 13 should definitely come off the list. I don't currently have any reason to stop supporting 8. But I'll consider it.

I would accept a patch to provide compatible mixed ESM/CJS mode if you can do that without introducing a build step. That is, consumers on Node 10 need to be able to continue to use the module without changing their code.

LJNeon

comment created time in 3 months

issue commentiarna/iarna-toml

NPM does not seem up-to-date

It's published to npm on a tag, so you can npm install @iarna/toml@3.0.0 and get it. Probably it is time to flip that to latest tho.

kefniark

comment created time in 3 months

issue commentiarna/iarna-toml

Can i do a PR to represent dates with timezone offset?

That seems pretty reasonable to me. I'd prefer to avoid config options: Let's go with it as the new default.

One special note: If the date is currently UTC, then let's not change the current representation. Eg, continue to use the Z shortcut.

randallb

comment created time in 3 months

issue commenttoml-lang/toml

Standard Test Suite for checking compliance of implementations

I'm really not splitting hairs: ISO8601 doesn't have a singular string representation for a given date. There are many valid representations of the same date. For ex 2020-12-12T00:00Z is the same as 2020-12-12T00:00:00.00-00:00. If you parse the field, as I've suggested, this is not a problem. If you're trying to stringify your dates and hoping the string representation is identical though...

cktan

comment created time in 3 months

pull request commenttoml-lang/compliance

Add tests for v1.0.0-rc from iarna's repository

@pradyunsg That would be fine

amanbh

comment created time in 3 months

issue commenttoml-lang/toml

Standard Test Suite for checking compliance of implementations

The string representation of dates in the test files is exactly as specified as the numbers. (Which is to say: Not at all.)

cktan

comment created time in 3 months

issue commenttoml-lang/toml

Standard Test Suite for checking compliance of implementations

My suggestion is the status quo, that is, staying with {"value": "1.0"}.

That said:

parse (only!) numbers

That's not true. You also have to do it for dates, another type that JSON can't represent.

For numbers, in practice implementers have just used their language native string->float or string->int functions. I think this is the right approach, as it moves the parsing requirement out of the test suite. The test suite should probably make some statements about what kinds of numbers are valid there -- for example, values that match ^-?\d+([.]\d+)?$ for floats and ^-?\d+$ for ints would be reasonable.

Dates in tests are more problematic, and currently underspecified. However, I think just saying that dates must be parsable by a ISO-8601 parser, should be sufficient. These aren't as ubiquitous the way decimal number parsers are, but as a rule are available as a library for every language we you are likely to want to make a TOML implementation for.

cktan

comment created time in 3 months

more