{"action":"created","issue":{"url":"https://api.github.com/repos/structured-log/structured-log/issues/28","repository_url":"https://api.github.com/repos/structured-log/structured-log","labels_url":"https://api.github.com/repos/structured-log/structured-log/issues/28/labels{/name}","comments_url":"https://api.github.com/repos/structured-log/structured-log/issues/28/comments","events_url":"https://api.github.com/repos/structured-log/structured-log/issues/28/events","html_url":"https://github.com/structured-log/structured-log/issues/28","id":172723572,"number":28,"title":"ES6 rewrite","user":{"login":"Wedvich","id":1078076,"avatar_url":"https://avatars.githubusercontent.com/u/1078076?v=3","gravatar_id":"","url":"https://api.github.com/users/Wedvich","html_url":"https://github.com/Wedvich","followers_url":"https://api.github.com/users/Wedvich/followers","following_url":"https://api.github.com/users/Wedvich/following{/other_user}","gists_url":"https://api.github.com/users/Wedvich/gists{/gist_id}","starred_url":"https://api.github.com/users/Wedvich/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/Wedvich/subscriptions","organizations_url":"https://api.github.com/users/Wedvich/orgs","repos_url":"https://api.github.com/users/Wedvich/repos","events_url":"https://api.github.com/users/Wedvich/events{/privacy}","received_events_url":"https://api.github.com/users/Wedvich/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/structured-log/structured-log/labels/enhancement","name":"enhancement","color":"84b6eb"}],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":1,"created_at":"2016-08-23T15:02:32Z","updated_at":"2016-08-24T18:11:02Z","closed_at":null,"body":"As mentioned in #27, I've begun experimenting with a rewrite of the current codebase to ES6 in this fork: https://github.com/Wedvich/structured-log. Not just because ES6 is cool (it totally is, though!) - but because the modern JavaScript syntax lends itself better to writing a clean, modular library. As mentioned in #17, it can be difficult to change or replace individual parts when everything is clumped together in one file. Splitting the code into multiple files/modules makes each moving part easier to reason about, but it's still not very elegant in ES5. So splitting code + ES6 seems like a good, future-proof solution.\r\n\r\nThe main focus now is to get it as close as possible to the current implementation, and basically pulling out the different components into separate classes without trying to restructure or change the internals.\r\n\r\nTo make sure it runs correctly in non-ES6 environments, a transpiler is needed to transform the code to ES5. I'm planning to use [Babel](https://babeljs.io) for this, as it's well-known and supported. In addition, it makes sense to distribute a single file rather than the whole set of source files, so a bundler is also required. [Webpack](https://webpack.github.io) and [Browserify](http://browserify.org) are the most common options here, but I'm leaning towards [Rollup](http://rollupjs.org) here as it avoids a lot of the internal infrastructure gunk of Webpack, so it seems like a better fit for a small library like this one.\r\n\r\nSome thoughts:\r\n\r\n- Should Bower support still be a thing? It depends on how much effort it takes. The bundle doesn't care if it's Node or a browser, so if a bower.json file is all it takes, I don't see why not.\r\n- I'd like to achieve more parity with Serilog when it comes to things like the log level names (`WARN`-> `Warning` etc.) and logging methods, to make the transition easy and predictable both ways.\r\n- Since there's no concept of extension methods in JavaScript as of yet, enabling syntax such as `.writeTo.consoleSink()` creates more coupling and mutation of the components that should be avoided. Sticking to `.writeTo(consoleSink())` is cleaner and more predictable.\r\n\r\nThere are some breaking changes that will need to be mapped out along the way and documented in an upgrade guide, but I think that should be acceptable since structured-log is still in a 0.x version.\r\n\r\nThoughts? Ideas?"},"comment":{"url":"https://api.github.com/repos/structured-log/structured-log/issues/comments/242158214","html_url":"https://github.com/structured-log/structured-log/issues/28#issuecomment-242158214","issue_url":"https://api.github.com/repos/structured-log/structured-log/issues/28","id":242158214,"user":{"login":"Wedvich","id":1078076,"avatar_url":"https://avatars.githubusercontent.com/u/1078076?v=3","gravatar_id":"","url":"https://api.github.com/users/Wedvich","html_url":"https://github.com/Wedvich","followers_url":"https://api.github.com/users/Wedvich/followers","following_url":"https://api.github.com/users/Wedvich/following{/other_user}","gists_url":"https://api.github.com/users/Wedvich/gists{/gist_id}","starred_url":"https://api.github.com/users/Wedvich/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/Wedvich/subscriptions","organizations_url":"https://api.github.com/users/Wedvich/orgs","repos_url":"https://api.github.com/users/Wedvich/repos","events_url":"https://api.github.com/users/Wedvich/events{/privacy}","received_events_url":"https://api.github.com/users/Wedvich/received_events","type":"User","site_admin":false},"created_at":"2016-08-24T18:11:02Z","updated_at":"2016-08-24T18:11:02Z","body":"Thanks for the quick feedback! I'll make sure to keep Bower support intact. As for Serilog parity, I'm okay with the rationale you provided - I just didn't know if it diverged out of coincidence or choice.\r\n\r\nI've managed to string the rewritten pipeline together now, so it's looking promising in terms of getting a testable version up and running soon. I'm working on updating the README as well, both to document the potential changes from the current version, but also because some of the features that are documented today are out of sync with what's actually available in the published package.\r\n\r\nOn the plus side, the upgrade path is very simple so far - these are the only changes from the current API:\r\n\r\n```js\r\n...\r\n\r\n.writeTo.consoleSink()      // no\r\n.writeTo(consoleSink())     // no for bundled sinks, 3rd party sinks make their own choice\r\n.writeTo(new ConsoleSink()) // yes\r\n\r\n...\r\n\r\nlog('stuff');      // no, log is now an object instance\r\nlog.info('stuff'); // yes\r\n\r\n...\r\n```\r\n\r\nOn a different note: now that the files are getting split up more and I'm taking advantage of ES6 class inheritance, I've been able to skip a bunch of the internal type/parameter validation. However, I also see an opportunity to sprinkle some TypeScript on top, as TS currently supports all ES6 features and is able to compile modules targeted at both ES6 and ES5. It's not an all-or-nothing deal either, since TS is a superset on top of ES6; any valid ES6 code is valid TS code, so we can apply it selectively where it makes sense.\r\n\r\nThis could completely eliminate internal type checks and move any validation logic up to the publicly exposed API surface, as internal type inconsistencies would be caught at compile-time by the TS compiler, which is an awesome prospect.\r\n\r\n@ProTip - you mentioned wanting to get TypeScript in here, what are your thoughts on this?"}}
{"actor":{"display_login":"Wedvich"}}